I love to work on open source projects, but from time to time I have my doubts. My friend Daniel Nauck created a wonderful open source licensing project (see my blog post) and now we had to see this:
I am not a lawyer and rebranding a tool might be permitted by the MIT license, but seriously what are they thinking?
They even removed license information from the source files.
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
It’s really ironic to violate the license of a licensing tool, but please don’t be that guy!
Tags:
C-Sharp,
portable.licensing
This is yet another blog post in my Currying and Partial application series. This is what I have posted so far:
In this post I want to show you a way to simulate type classes in C# and F#. Type classes are this wonderful feature in Haskell which allow you to specify constraints on your polymorphic types. We don’t have this in C# nor F#.
Let’s start with the following problem: We want to compute the sum of the squares of arbitrary numbers. We want to write something like this:
The problem is we don’t have a generic * function and of course we’d also need a generic + operator and maybe a generic zero. Obviously we need a constraint on the generic parameter T since + might not be defined for any type. So let’s define an interface for numbers:
Nothing special here, so let’s get straight to the implementation for integers and doubles:
So far so good. With this in our pocket we rewrite SumOfSquares() into this:
The trick is that we pass the concrete implementation as the first parameter into our function. This works exactly like a type constraint or as Simon Peyton-Jones would say: the vtable travels into the function. Notice that we don’t have access to the definition of in nor double. There is no way for us to express that int or double implement a number interface.
Now let’s try this out:
As you can see, this is perfectly type safe. We now have a way for poor man’s type classes in C#. Yay!
Now what has this to do with partial application? Let’s look at the same thing in F#:
We’re using a lot of partial application here. Exercise: Try to spot all the places.
Ok, you’re right. This post might be a little bit far away from the partial application stuff, but it’s still related. Somehow.
Tags:
C-Sharp,
Currying,
F#,
partial application,
type classes
In the last couple of days I started to write some posts about Currying and Partial application:
This time I want to show you how we can write a higher-order function which allows us to curry another function. Remember the multiplication function from the first post and it’s curried form:
Currying
The question is: how can we automate this transformation process? Remember we want to have the curryied form for partial application:
Let’s look at the signature of the desired Curry-function: in our case it has to take Func<int, int, int> and returns Func<int, Func<int, int>>.
If we generalize the ints to generic parameters and fix the signature then the implementation is trivial (Compiler Driven Programming). There is exactly one way to make this work:
The F# implementation does exactly the same, but without all the annoying the type hints:
Uncurrying
Of course you can undo the currying by applying a generic Uncurry-function:
And in F# this looks like this:
Libraries
Currying and Uncurrying are two very important concepts in functional programming so they are included in a couple of libraries:
- You can find it at the top of the Prelude in FSharpx (read more).
- You can find it in the Haskell Prelude.
- You can find similar functions in Scalaz.
- Adrian Lang wrote a library called partial-js which allows to do something similar in JavaScript.
Tags:
C-Sharp,
Currying,
F#,
partial application
Friday I attended the .NET BootCamp “NHibernate vs. Entity Framework” in Leipzig and as always it was a pleasure for me being there. Afterwards I had a nice talk with my friend Alexander Groß about the Open/Closed Principle. I didn’t really care about this principle before, but now I think it’s really a nice idea:
“In object-oriented programming, the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be modified without altering its source code.”
[Wikipedia]
If we follow this principle we get lot’s of small and testable classes. I want to demonstrate this with a simple spam checker for mails.
Let’s say our mail class has only a sender, a recipient, a subject and the mail body:
public class EMail
{
public string Sender { get; set; }
public string Recipient { get; set; }
public string Subject { get; set; }
public string Body { get; set; }
public EMail(string sender, string recipient,
string subject, string body)
{
Sender = sender;
Recipient = recipient;
Subject = subject;
Body = body;
}
}
public enum SpamResult
{
Spam,
Ok,
Unknown
}
Now we want to know if a mail is spam or not. Of course we need some rules and some kind of “rule checker” to decide this. Here is a very naïve implementation for this:
public class RuleChecker
{
public SpamResult CheckMail(EMail mail)
{
var result = TestRule1(mail);
if(result != SpamResult.Unknown)
return result;
result = TestRule2(mail);
if (result != SpamResult.Unknown)
return result;
// …
return SpamResult.Unknown;
}
private SpamResult TestRule1(EMail mail)
{
// I don’t care about the concrete rules
}
private SpamResult TestRule2(EMail mail)
{
// I don’t care about the concrete rules
}
}
It is obvious that this implementation breaks the Open/Closed Principle. Every time someone comes up with a new anti-spam rule or the rule priorities change I have to modify the code in CheckMail(). Another problem here is that I can’t test CheckMail() isolated from the concrete rules.
With the help of the Open/Closed Principle our implementation could look like this:
public interface ISpamRule
{
SpamResult CheckMail(EMail mail);
}
public class RuleChecker
{
private readonly IEnumerable<ISpamRule> _rules;
public RuleChecker(IEnumerable<ISpamRule> rules)
{
_rules = rules;
}
public SpamResult CheckMail(EMail mail)
{
foreach (var rule in _rules)
{
var result = rule.CheckMail(mail);
if (result != SpamResult.Unknown)
return result;
}
return SpamResult.Unknown;
}
}
Now you could easily write isolated UnitTests for RuleChecker.CheckMail() and for every new rule.
You get the your concrete RuleChecker by calling the constructor with a list of rules:
class MyFirstRule : ISpamRule
{
public SpamResult CheckMail(EMail mail)
{
// I don’t care about this
}
}
class MySecondRule : ISpamRule
{
public SpamResult CheckMail(EMail mail)
{
// I don’t care about this
}
}
// …
var ruleChecker =
new RuleChecker(
new List<ISpamRule>
{
new MyFirstRule(),
new MySecondRule(),
// …
});
Alex please correct me if I’m wrong, but I think this is what you had in mind Friday.
As stated before, we end up writing lot’s of very small classes – mostly with only one (public) method. I think this is some kind of functional approach, the only question is how we glue our code entities together. Let’s look at the corresponding F# implementation:
type EMail =
{ Sender: string;
Recipient: string;
Subject: string;
Body: string}
type SpamResult =
| Spam
| OK
| Unknown
let checkMail rules (mail:EMail) =
let rec checkRule rules =
match rules with
| rule::rest ->
match rule mail with
| Unknown -> checkRule rest
| _ as other -> other
| [] –> Unknown
checkRule rules
The signature of checkMail is (EMail -> SpamResult) list -> EMail –> SpamResult, which means it takes a list of rules (as above the order is important) and a EMail and returns the SpamResult. In addition I exchanged the explicit foreach loop with a tail recursion to make it look more functional.
If I want a concrete rule checker I could use partial application:
let myFirstRule mail =
// I don’t care about this
let mySecondRule mail =
// I don’t care about this
// val ruleChecker : (EMail –> SpamResult)
let ruleChecker =
checkMail
[ myFirstRule;
mySecondRule]
As you can see the F# implementation is nearly the same as the C# implementation, just without explicitly wrapping our public method in classes. If we would use Reflector we would see that the F# compiler is building the classes around our functions. One could say if we follow the Open/Closed Principle we come to functional code or the other way around if we write functional code we automatically apply the Open/Closed Principle. I think that’s why I really didn’t care about this before.
Appendix
After thinking about this implementation and the extra type hint (see mail:EMail) I came up with a slightly more generic implementation:
type SpamResult =
| Spam
| OK
let checkRules rules element =
let rec checkRule rules =
match rules with
| rule::rest ->
match rule element with
| None -> checkRule rest
| _ as other -> other
| [] –> None
checkRule rules
Here I deleted the enum value for SpamResult.Unknown and used the standard None option. As a consequence the signature changed to: val checkRules : (‘a -> ‘b option) list -> ‘a -> ‘b option. The function still takes a list of rules and a element and returns a option value. Now the checkRules function works with every kind of rule result and takes arbitrary elements.
Tags:
.NET Usergroup Leipzig,
C-Sharp,
F#,
Open/Closed Principle,
SOLID
