RSS 2.0 | Atom 1.0

Sign In


# Tuesday, September 16, 2008
Why NOT F#?
This is actually an open request for comments. I'm honestly interested in hearing why F# is not always the better candidate versus C#. What can C# do well that F# cannot? In nearly everything, F# seems to come out on top, as far as I can see.

Let's get these out of the way:

   - Personal preference. Enough said.
   - In beta. Enough said.
   - Legacy code. Sure, if you have a project in C#, it may not make too much sense to switch mid-way.
   - Management. Enough said.
   - No benefit. This is simply lack of education and needs to be addressed separately.
   - F#'s too hard/it's hard to hire F# devs. This is a non-issue that is a separate topic. In summary, anyone worth hiring for C# work should be able to handle F#. [Exception being a very small deadline with an existing team...]

The only code reason I've seen is heavy native interop/pointer work. F# seems to be slightly more verbose than C# in this case. It's not much more, but I could see if you're doing just pointer code then it could get annoying. (Interestingly enough, F# COM interop is much nicer than C# because it supports named and optional parameters (http://blogs.msdn.com/dsyme/archive/2008/05/02/full-release-notes-for-f-1-9-4.aspx, search for "chart")...)

What other reasons are there for C# over F#?

Edit: Good point in the comments about C# being a standard with open source implementations. That could be a big issue for some. Another good point is the current lack of tool support (like ClickOnce, ASPX and WPF designers, etc.). I don't see any intrinsic reason F# wouldn't have those, except for limited resources.

Code | FSharp
Tuesday, September 16, 2008 5:06:28 AM UTC  #    Comments [18]  |  Trackback

MARS is case-sensitive for LINQ-to-SQL
When specifying a connection string to use with LINQ-to-SQL, make sure you "correctly" case MultipleActiveResultSets. If you have something like this: "Server=(local);Database=master;Integrated Security=true;App=dcdemo;MultipleActiveResultsets=true", LINQ-to-SQL will determine MARS is disabled even though it is not.

This is because inside the LINQ-to-SQL implementation, a normal String.Contains is performed on the connection string. Since this is an ordinal compare, it won't find MARS turned on if you spell it differently. Without MARS enabled, if you execute multiple queries on a single DataContext, it will force the outstanding queries to buffer. This means that instead of a nice lazy reading from the SQL server, you'll end up bringing it all into local memory.

More info here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=366444

Tuesday, September 16, 2008 5:02:00 AM UTC  #    Comments [0]  |  Trackback

# Tuesday, September 02, 2008
Become a better F# programmer via Real World Haskell

There are other great books out there such as Expert F#. The F# Dev center has links to many other "learn F#" articles. All of these are great.

But, something I found helpful is going "purely functional", and Haskell is the perfect vehicle. When you're forced to think only functional, and don't have the other "escapes" F# has, you bend your mind into understanding how you can accomplish things without using mutation or object-orientation.

The downside of Haskell is that many resources seem to be very challenging to get into. There's no doubt that the learning curve for Haskell can be tough. On top of that, many materials tend to dive right into monads and it tends to end up too scary. I've even bought several other good books on functional programming, but none of them were easily approachable. (They have good content, but you can't start from zero by using them.)

Enter Real World Haskell. This is a *very* easy to follow book and really drives functional programming home. It doesn’t assume you know anything about functional programming at all, so the learning curve is a gentle slope.

Even better? It's completely available online, so you can start reading it right now! Plus, it has reader-submitted comments which are of tremendous use, as they ask and answer many common questions that might arise as you read along, without interfering with the flow. You can read the entire book here: http://book.realworldhaskell.org/read/ [But buy it to support the excellent work the authors have done!]

I've found that my F# skills have gone up tremendously by reading Real World Haskell. For instance, I "sorta" understood F#'s computation expressions and builder. Say, enough to use them -- that's easy, like most things in F#), but understanding the concepts behind them? Starting to learn Haskell really brings the understanding around. This isn't to say that you'll eschew mutation and OO in F# -- such concepts can be very useful (and increase performance on the CLR). But at least you'll know when a more elegant solution is available.

(Plus, it's fun! As someone in #haskell on freenode put it to me: "Learning Haskell will f*ck with your brain, and you'll like it.")

Code | FSharp
Tuesday, September 02, 2008 4:00:06 AM UTC  #    Comments [4]  |  Trackback

Mono in FreeSWITCH - Experience in embedding Mono
Managed code? In MY softswitch? It's more common than you think.

A while back, I tried creating a mono plugin for Asterisk. The goal being that'd you'd be able to write in-process apps in decent languages, rather than resorting to C. Well, there were no standards of how functions operated (i.e., who's responsible for memory), and my requests to standardize these were met with hostility. (Actually, when I asked why they didn't refactor some stuff, like the multi-thousand-line switch statements, I was told "refactoring doesn't exist for C"... sigh.) But the real showstopper was that we couldn't figure out how to get Asterisk to play nice with mono as far as threads go. I had a very active Asterisk developer work on it with me, and he pretty much told me it wasn't going to work. Oh well.

When I stopped really being involved with Asterisk, I had seen a couple big Asterisk developers leave to start FreeSWITCH. It was mainly an idea at that point, to do things right and build a scalable, clean system. Well, fast forward a few years and FreeSWITCH has really come far. You can go read their site for more details, but it's a more flexible, scalable, and vastly cleaner VoIP platform. That's why, at v1.0.1, it already supports UDP, TCP, TLS, SRTP, IPv6, wideband codecs, and more. Oh, and it runs cross-platform, including Windows.

But the really great thing about FS is that it was designed to be modular from the beginning. And, it was designed to allow people build apps into it. It has some nice out-of-process extensibility, think Asterisk Manager and AGI, without the suck. [I wonder how many * flames I'm gonna get?] But also of interest, they designed an app API from the start. It's written in C++, and SWIG friendly so you can quickly add other languages (Javascript and Lua seem to be the most popular).

Well, the thought of running interpreted stuff in-process disgusted me, so I immediately set out to try to add Mono support. Much to my surprise, the FS team was extremely supportive. They helped me figure out all the bits of FS and the API I needed. In fact, one of the project leads told me, "Hell, if you're gonna write mod_mono, we'll give you checkin support right now.". A short bit later, we had mod_mono working!

Not satisfied with doing just apps, I turned to doing a full integration. A bit of SWIGwork later, and I had the entire FreeSWITCH header files SWIG'd and C# accessible. I found a few APIs that didn't import (varargs stuff, I think), but the FS team helped add some different methods to work around that.

The Mono side was pretty straightforward. We write a C/C++ module for FS that gets Mono up and running. Then it kicks off mod_mono_managed, which actually loads modules, runs initialization code, etc.
The biggest problem I ran into was a problem between SWIG and Mono. Mono would attempt to free strings with g_free, crashing on Windows. I wrote a SWIG-C# post-processor to tweak the SWIG code to avoid it; I'm not sure it's accurate, but we haven't noticed issues so far. A few things we ran into were quickly cleared up by the awesome people #mono. This week we'll be testing and make sure it's fixed in Mono 2.0.

So, the bottom line is that you can write any sort of module for FreeSWITCH, from simple apps and API functions, down to a full codec or endpoint, all in managed code (though, the interop might not be pretty sometimes). I've tried some simple stuff out in C#, F#, and Javascript (JScript .NET), and it all works fine. The code is in the FS SVN, under /freeswitch/src/mod/languages/mod_mono and mod_mono_managed. It's not part of the official build yet, so there may be a bit of work involved in getting it going. But I have heard from other people that they've gotten it working. Some info is here: http://wiki.freeswitch.org/wiki/Mod_mono -- Right now, we've only tested on Mono 1.9.1, but we're going to only support 2.0 as of very soon. (F# only supports 2.0, so earlier versions are irrelevant to my interests :).)

This is exciting for us, as it allows us to build *safe* applications that run in-process with the switch. But, unlike the embedded scripting languages, we get top-notch performance and access to complete libraries. We're combining this in-process approach with out-of-process (Event Socket, outbound) to get a robust and very scalable system. For our particular application, we have several GB of decision data that we keep in RAM on separate servers (which is in turn sync'd to SQL Server 2008, via a proprietary change replication system). For obvious reasons, we didn't want that memory being stuck in the FS process. Having Mono on both sides allows us to share code between the different systems, while still getting optimizations for both environments.

You can email me: mgg AT a t r e v i d o _ net or use the chat widget on the on my site if you have questions or problems getting it going.

I'll post a follow up once it's in the official build.

Tuesday, September 02, 2008 2:04:38 AM UTC  #    Comments [0]  |  Trackback

# Sunday, August 31, 2008
Statically typed duck typing in F#
Many times when I talk to a pro-dynamic typing person, they bring up duck typing. And when I say that duck typing could be resolved statically, I usually get wierd looks, or worse. Well F# exposes static duck typing to users. At least, using the definition that C# uses for duck typing of foreach and collection initalizers. (Yes, of course its a compiler feature and not true CLR/runtime checking.) I'm not promoting this, just pointing it out for fun.

F# allows inline values to accept "statically resolved type variables". The F# specification says (§5.1.2):
A type of the form ^ident is a statically resolved variable type. A fresh type inference variable is created and added to the type inference environment (see §14.6). This type variable is tagged with an attribute indicating it may not be generalized except at inline definitions (see §14.7), and likewise any type variable with which it is equated via a type inference equation may similarly not be generalized.
At the end of this post I have a simple example to help understand this kind of type variable. But more interesting is a another constraint you can apply to such type variables. § Member Constraints: "A constraint of the form (typar or ... or typar) : (member-sig) is an explicit member constraint." But, inside the the F# library, this form is used with function application! For example, the char function is defined:

let inline char (x: ^a) =
    (^a : (static member ToChar: ^a -> char) (x)) // Function application!
     ...<snip /> --
I removed all the special case and inline IL code as its irrelevant for this post

Well, if we have member constraints with function application... we have "statically typed duck typing":

let inline speak (a: ^a) =
    let x = (^a : (member speak: unit -> string) (a))
    printfn "It said: %s" x
    let y = (^a : (member talk: unit -> string) (a))
    printfn "Then it said %s" y

type duck() =
    member x.speak() = "quack"
    member x.talk() = "quackity quack"
type dog() =
    member x.speak() = "woof"
    member x.talk() = "arrrr"

let x = new duck()
let y = new dog()
speak x
speak y


It said: quack
Then it said quackity quack
It said: woof
Then it said arrrr

The restriction is that you have to use inline to get generalization*. If it's not inline, then it'll add additional constraints based on usage. If you removed inline in this case, you'd get the following:

warning FS0064: This construct causes code to be less generic than indicated by the type annotations. The type variable 'a has been constrained to be type 'duck'.
error FS0001: The type 'dog' is not compatible with the type 'duck'.

Inline is as it sounds - the IL code is emitted inline, which is obviously a drawback in many cases. But that's the only way it can work - it has to statically know what types and compile the right method info into the binary. I suppose it'd be possible for the CLR to support this intrinsically. That way, the JIT could emit much more optimized code, versus creating a new method for reach type. I don't know dynamic languages well enough to know if this would be at all a help for interop.

*Here's a simple example to demonstrate the difference between 'a and ^a type parameters generalization.

> let id (a : 'a) = a;;
val id : 'a -> 'a

> id 1, id "hi";;
val it : int * string = (1, "hi") // Good, it's generic

> let id (a : ^a) = a;;
  let id (a : ^a) = a;;
stdin(8,14): warning FS0064: This construct causes code to be less generic than indicated by the type annotations. The type variable 'a has been constrained to be type 'obj'.

val id : obj -> obj

> id 1, id "hi";;
val it : obj * obj = (1, "hi") // Constrained to obj - not generic

> let inline id (a : ^a) = a;;
val inline id :  ^a ->  ^a

> id 1, id "hi";;
val it : int * string = (1, "hi") // Since it's inline, it's generic

Sunday, August 31, 2008 1:14:34 AM UTC  #    Comments [4]  |  Trackback

# Saturday, August 30, 2008
F# CTP Comment Selection
I find myself using "Comment Selection" often as I hack up quick scripts. Before the F# CTP, doing "Comment Selection" (Ctrl-K, Ctrl-C) would simply add (* *) around the selection. This makes it hard to uncomment specific lines. Now it goes and adds // in front of each line. Small things like this, in aggregate, decide a great IDE. For as much as I dislike some C# language decisions, their code editor is the best of anything I've ever seen.

Oh yea, the IntelliSense is also now WAY better. What's still missing is the "always active autocomplete", although I suspect this is harder in F#'s #light syntax than in C#.

Saturday, August 30, 2008 6:10:59 PM UTC  #    Comments [0]  |  Trackback

# Friday, August 29, 2008
No, really, the Event-based Asynchronous Pattern IS bad
Came across this:

His main point is that async total sucks, but that "Events don’t necessarily make async code tragically unreadable!" As a demonstration, he shows some simple async HTTP code without full or exception continuations. His code just enforces my point.

At any rate, yes, sure, if your continuation code isn't too related to your calling code, events can work. I mentioned this in my post: "events are a bad choice for code that is not loosely coupled" followed with "sometimes a simple delegate field would be a better choice". Indeed, looking at Mike's sample code, it seems as if using a simple delegate field would allow some nice refactoring.

But a point of the Event-based Asynchronous Pattern is, and I quote, to "Wait for resources to become available without stopping ("hanging") your application". So basically, you want to take an existing method, say, in response to a user action, but you can't let it block. This is exactly perfect for a continuation based approach and not so much for a loosely-coupled event-based approach. The act of "firing" an event should indicate that you're letting _other listeners_ (notice the plural) know when you did something.

More on when events are appropriate: Say you're listening for SNMP messages and when you receive one, you let "everyone" know that you did. You don't care what they do with the result, and they just go off on their own. Events can work. Or, take, for example, the BackgroundWorker. The BackgroundWorker doesn't help thread your blocking code, it just pushes the block to a background thread you don't care about. Your HTTP code will still be all sync, and you'll still burn a thread. BackgroundWorker main help is that it coordinates back to your "UI" thread, since many UI frameworks have strong thread affinity and will crash otherwise.

But that was the whole point
The event async pattern, specifically in things like Silverlight, is completely aimed at *not letting the thread block*. That's the _only_ problem it is trying to solve. Silverlight only forces this because the main thread is the UI thread, and they won't want the browser hanging by dumb apps that don't put the block on a background thread. If they didn't want to do continuations, they could have at least kept the sync APIs, and thrown an exception if called from the main thread (thus letting people who know what they're doing not have to deal with the ugly event syntax).

BTW, F# kicks the crap out of your language
I didn't mention it in my previous event post, but F#'s computation expressions let you deal with continuations in a totally sexy way. H.H. Don Syme, writes about it here: Introducing F# Asynchronous Workflows. You learn F# if you don't know it. But just to demonstrate, here's an example from that introduction:

    let AsyncHttp(url:string) =

        async {  // Create the web request object

                 let req = WebRequest.Create(url)


                 // Get the response, asynchronously

                 let! rsp = req.GetResponseAsync()


                 // Grab the response stream and a reader. Clean up when we're done

                 use stream = rsp.GetResponseStream()

                 use reader = new System.IO.StreamReader(stream)


                 // synchronous read-to-end

                 return reader.ReadToEnd() }

The let! binding handles things asynchronously; the rest of the body becomes a continuation. If that isn't superior to any C# approach and doesn't make async easy, I don't know what would.

Code | FSharp
Friday, August 29, 2008 9:03:55 PM UTC  #    Comments [0]  |  Trackback

The most anticipated release of the year is out: F#
A huge thank you and congratulations to MSRC and the F# team! (And to MSFT in general for taking their commercial languages up quite a few notches.)


I was up late last night reading different things on MSR and came across Andrew Kennedy's page. What a surprise to see this morning that F# includes Units of Measure Inference and Checking. http://research.microsoft.com/~akenn/units/intro.html Edit: Oh cool, Mr. Kennedy now has a blog and goes into detail: Units of Measure in F#: Part One, Introducing Units

It seems they did a ton of general clean up and added consistency with .NET and so on. (For instance, you don't need to explicitly accept subtypes with #.)

There's also an "AutoOpen" feature for modules, which allows modules to automatically get opened if their container namespace is -- I suppose this allows more namespace oriented development like .NET prefers. 

Too much stuff to understand the full impact just by browsing the release notes. I think the license has changed; at least it's quite clear that our commercial plans with F# are perfectly allowable (there was some question before). So, now it gets interesting...

Friday, August 29, 2008 7:19:13 PM UTC  #    Comments [1]  |  Trackback

# Thursday, August 28, 2008
Tsk, tsk, Silverlight - Events are not async's friend
OK, so Silverlight 2 is still in Beta 2 and hopefully will have time to change. But I would have thought this fix would have gotten into Beta 2 (as far as I can tell, it has not). At any rate, it applies to async design in general.

Scenario: You are writing an async method and need to call code when your async process finishes. How do you expose this to your caller? For some reason (I'd love to know what it is), it seems to be getting more popular to expose an event to accomplish this.

Events suck: Let's use a simple case. You want to get two URLs, using the return of one to get the other, then print the result to the console. You have a few local variables you need to use as well. Let's see what it'd look like without async:

// Inside some method:
var url1 = Console.ReadLine();
var url2 = Console.ReadLine();
var someData = Console.ReadLine();
// onEx = some exception handler
try {
    var res1 = webThingy.Download(url1);
    var res2 = webThingy.Download(url2 + "?data=" + res1.Data);
    Console.WriteLine(someData + res2);
} catch (Exception ex) {

Straightforward, eh? Now, with async + events? You _could_ go create a new object type and add all sorts of fields and methods and whatnot, but that's a lot of work and gets ugly quickly. Closures are a natural help here. So how does the event-based async code look?

// Inside some method:
var url1 = Console.ReadLine();
var url2 = Console.ReadLine();
var someData = Console.ReadLine();
// onEx = some exception handler
OnDownloadCompleteEventHandler first;
webThingy.OnDownloadComplete += first = (o, res1) => {
    if (res1.Exception != null) {
    webThingy.OnDownloadComplete -= first;
    webThingy.OnDownloadComplete += (o2, res2) => {
        if (res2.Exception != null) {
        try {
            Console.WriteLine(someData + res2.Data);
        } catch (Exception ex) { onEx(ex); }
    try {
        webThingy.DownloadAsync(url2 + "?data=" + res1.Data);
    } catch (Exception ex) { onEx(ex); }
try {
} catch (Exception ex) { onEx(ex); }

I think this judges itself.

The way it SHOULD be is that any async method should take two arguments, one to call for result, one for exception. Let's see how that would look:

// Inside some method:
var url1 = Console.ReadLine();
var url2 = Console.ReadLine();
var someData = Console.ReadLine();
// onEx = some exception handler
webThingy.DownloadAsync(url1, onEx, res1 => {
    webThingy.DownloadAsync(url2 + ?data=" + res1, onEx, res2 => {
        Console.WriteLine(someData + res2);

This code isn't perfect, but it's sure a ton better than the event-based system. With a bit extra work, you could build a simple async framework. Every Async method could return an Async object that would allow you to consolidate stuff like exception handling and cancellation. But even without that, this code straight away is much superior.

The extra downside
Interestingly enough, .NET 1 had the concept of BeginXXX/EndXXX, but because there were no closures, it was always a bit more of a pain to implement. BeginXXX/EndXXX, while not making exception handling as easy, are at least a good start.

The cool thing about BeginXXX/EndXXX was that you could refactor them generically into nice async syntax. Heres a quick and dirty example [F#'s async stuff works similarly.]:

static Action<A1, Action<Exception>, Action<R>> ToAsync<A1, R>(
    Func<A1, AsyncCallback, object, IAsyncResult> begin,
    Func<IAsyncResult, R> end) {
    return (arg, onEx, cont) => {
        begin(arg, iar => {
            try { cont(end(iar)); } catch (Exception ex) { onEx(ex); }
        }, null);
static void BeginAcceptAsync(this Socket s, int timeout,
    Action<Exception> onEx, Action<Socket> cont) {
    ToAsync<int, Socket>(s.BeginAccept, s.EndAccept)(timeout, onEx, cont);
static void Main() {
    Socket s = ...;
        ex => Console.WriteLine(ex),
        sock => sock.Close());

(Yes, I think this is a legitimate use of type extensions, but again, only because the original library had a design flaw. And even the non-extension syntax wouldn't necesarily be bad.)

But, to my knowledge, since there's no way to reference an event, this is not possible with the async + event approach t hat is becoming all the rage (yes, SocketAsyncEventArgs, I'm talking about you too). If you know of a way to ease the pain of async+events, tell me.

In summary
It seems that events are a bad choice for code that is not loosely coupled, such as UIs. Even when loosely coupled, sometimes a simple delegate field would be a better choice, since you can compose (like tacking on a filter or otherwise augmenting the callback). But in the case of async, I cannot see how it is good.

Thursday, August 28, 2008 1:48:31 AM UTC  #    Comments [1]  |  Trackback

Why are there still delegates?
Can someone explain to me the point of having delegate types in C#/.NET? They made sense in the non-generic .NET 1 world, but with generics they should have no reason to exist (except maybe purely as a type alias). All the delegates in common use are representable with a generic definition (think Action/Func<...>). But for some reason, you cannot automatically use an equivalent delegate in C#.

This manifests a bit more when you consider a local such as:

var inc = (int x) => i + 1;

As Expression<T> syntax takes the same form, the compiler cannot tell if it's an expression or a delegate. Additionally, since Func<int,int> is "just as good" as any other generic type, even if the compiler wanted to create a delegate, it wouldn't know to use Func<int,int>. Thus, you must specify it, and inner functions are too clunky to be used in C#.

The answer I got from Microsoft (not an official answer, just a response to a Connect item) was that C# might allow auto-conversion in version 4, but also that delegates aren't totally useless because recursive delegate types can't be declared in that fashion. But for the relatively few uses (fixed-point combinators?) of such types, built-in, specific support would be a small sacrifice, wouldn't it?

This is just something I've been wondering about.

Update: Thanks for Jonathan Pryor for pointing out in the comments what my limited functional mind missed: ref/out parameters and of course, and high-arity delegates. While these should be easy to work around, they are accurate technical reasons. Thanks.

Thursday, August 28, 2008 12:18:44 AM UTC  #    Comments [11]  |  Trackback

# Wednesday, August 27, 2008
ASP.NET MVC Begs for Tuples

[Yea, I’m not a web dev, and actively avoid it as much as possible, so I’m late to this party.]

The interesting thing about ASP.NET MVC is that it takes an opposite approach to ASP.NET in general. ASP.NET concepts try to “build up”, so as to shelter us from the evolved idiocy that is HTML, as well as clean up the inherently stateless nature of HTTP. ASP.NET MVC makes no attempt and forces you to deal with reality. Considering ASP.NET’s abstraction isn’t really perfect (example: databinding sucks), MVC’s approach is unfortunately refreshing.

Because of its “raw” nature, you’ll be writing a lot more HTML than you’d do with ASP.NET, and this HTML must line up with code on your server. To make this less of a pain, there are some HTML helper functions. Rob “ type inference” Conery has an overview here.

Here’s the signature for one of the functions:

    public static string CheckBox(this HtmlHelper helper, string htmlName, string text, string value, bool isChecked, object htmlAttributes);

The last parameter confused me. Why would it be an object? Am I supposed to pass in an IDictionary<string,string>? Just a long string? To make it more confusing, other helpers had two overloads:

    public static string TextArea(this HtmlHelper helper, string htmlName, object value, IDictionary<string, object> htmlAttributes);

    public static string TextArea(this HtmlHelper helper, string htmlName, object value, object htmlAttributes);

OK, so they explicitly called out the IDictionary there – THEN WHO WAS OBJECT HTMLATTRIBUTES?

Rob covers in his overview. The idea is that you’re supposed to use anonymous types to hack around the lack of tuples.

<%=Html.Whatever(arg1, bla, …,
                             new { @class=”cssx”, style=”x:f” …}) %>

What a great case of not-having-built-in-tuples-is-lame. It’s so lame, Microsoft’s own developer teams have to resort to weird (but quite creative!) hacks like this so that their syntax won’t completely suck*. Damn.

And now, a duck

For bonus points, there is another C# compiler feature that the MVC team could have [ab]used, and it would arguably have made more sense (although the syntax isn’t as tight). C# supports duck typing on collection initializers! So, they could create a class like this:

    public class HtmlAttributes : System.Collections.IEnumerable


        public System.Collections.IEnumerator GetEnumerator() { ... }

        public void Add(string name, object val) { ... }


And then they can write this:

new HtmlAttributes { { "A", 123} , {"B", "test"} }

No, it’s not as tight as the anonymous type syntax, but it does make a lot more sense.  And tuples still make much more sense than either approach, and have benefits for the rest of the language to boot (death to out parameters!).

 *The only benefit I see in anonymous types is that, at compile time, you'll  know there are no key conflicts - but that is totally trivial in the way they use them, since all the keys are declared right there.

ASP.NET | Code
Wednesday, August 27, 2008 1:12:13 AM UTC  #    Comments [10]  |  Trackback

Extension Methods Suck
Been meaning to write this for a while, and I think I touched on it here, but I'd like to expand a bit. C# Extension Methods are just a hack to compensate for C#'s poor handling of functions in general. As far as I can tell, they were added solely so you can do this type of thing in LINQ:

  var squares = myInts.Select(i => i * i)

Instead of:

  var squares = Enumerable.Select(myInts, i => i * i)

In other words, they wanted to provide some simple infix syntax for functions. Well, that's a poor approach to the problem.

    - First off, it only works on function specially declared to be "extensions", which means your composition options are limited to whatever the library has built in. I can't send arguments to arbitrary static methods, like, say, "someVar.Console.WriteLine".

    - Second, since extension methods are defined solely by their method name, ambiguity is quite easy to come across. There's no way to qualify Foo.Function versus Bar.Function.

Other languages approach this with two simple things (which actually simplify the entire language/type system overall). First off, we need to be able to define function operators. I'll demonstrate with F#'s pipeline operator:

    let (|>) x f = f x

[As a side note, any language that lets you toss around operators and functions will allow this kind of syntax – it isn’t that F# had to have compiler support for this particular operator.]

In fake C#, it’d be something like (for fun, notice the lack of type inference):

B operator|> <A, B>(A x, Func<A, B> f) { return f(x); }

This means that the |> operator will take x on the left and apply it to f on the right side. If this existed in C#, you'd be able to write something like:

    "Hello" |> Console.WriteLine
    if (myInts |> Enumerable.Any) { .... }

Now we can pass in a parameter to static methods. But, hey, whaddya know? With this, Extension Methods are solved for all single-argument static methods! That was easy. But what about Select – it takes two parameters, so this won’t work.

Enter the Lambda
What if ALL functions took one parameter and output one parameter? If that were the case, then we’d be set. But how do allow more than one parameter? Well, what if, every time you declared a method with more than one parameter, it actually returned a method that took the next parameter? For example, we could write “Add” as:

        Func<int,int> Add(Func<int,int> a) { return b =>  a + b; }

This is known as the curried form of Add. We’d now call it as: Add(5)(6). We can do cute stuff like “var inc = Add(1)”. But, as the Add declaration shows, in C# this is too unwieldy (and this is a simple example!). The compiler should actually do all this for us, so we can just write our functions normally but use them as if they were written in curried form.

Now, if we simply swap the order of arguments for Enumerable.Select, we have our extension method ready to roll: Enumerable.Select(Func, IEnumerable) can be used so:

var squares = myInts |> Enumerable.Select(i => i * i)

Now the call to Select takes the lambda (i * i) and returns a function that takes an Enumerable. It is then given the myInts, and everyone is happy. This is just a quick, crap, explanation. Google can lead you to many more interesting resources about partial application, currying and so on.

At any rate, I think if C# had taken this approach, we'd all be much better off. To top it off, more functions would take their arguments in a proper style. As it is, uncurried versions of Extension Methods are incompatible with normal function pipelining. Oh well.

Code | FSharp
Wednesday, August 27, 2008 12:17:53 AM UTC  #    Comments [15]  |  Trackback

# Tuesday, August 26, 2008
ASP.NET MVC - Abusing Using (At VB's request?)
Someone on our team started using ASP.NET MVC for a new web interface we're doing. I must say I'm impressed with the level that the MVC team [ab]uses the C# compiler, mostly in a good way. On the plus side, they end up with a bit more compiler time checking than would be possible otherwise (we can only hope WPF will follow suit some day).

But one thing struck me odd was how their helper method for generating an HTML form works. The goal is to generate an HTML form tag with the right action, and they use lambdas as symbolic references to figure out the action. The next problem is making sure that the <form> gets closed with a </form>. The straightforward answer to this is "create a function that takes a function". The C# signature would be: void Form<A>(Expression<Action<A>>, Action). Then your ASPX code would be:

<% Html.Form<FooController>(x => x.Edit(someVar.FieldX), () => { %>
    Some Html <% SomeCode%>
<% }); %>

The code is nicely bracketed and works fine. But ASP.NET MVC doesn't actually do that. Instead, the Form method returns an IDisposable! The code to use it is:

<% using (Html.Form<FooController>(x => x.Edit(someVar.FieldX)) { %>
    Some Html <% SomeCode%>
<% } %>

Why do they use an IDisposable? The rest of the MVC framework seems to assumes people are somewhat familiar with lambdas, closures and what not. The only thing I can think of is that VB doesn't support anonymous methods. So in order to make it VB friendly, they come up with quite a strange use of IDisposable to abuse language support for it. Overall, I'm not sure if this is dumb or cute.

Code | ASP.NET
Tuesday, August 26, 2008 9:19:59 PM UTC  #    Comments [4]  |  Trackback

# Saturday, August 16, 2008
Reference cells in F# sequences
I saw this stack implementation (http://blogs.msdn.com/jaredpar/archive/2008/08/15/immutablestack-in-f.aspx) and wanted to see how I'd approach it:
open System

type 'a ImmutableStack =
   | Empty
   | Stack
of 'a * 'a ImmutableStack
member x.Peek() = match x with | Stack (v, _) -> Some v | _ -> None
member x.Pop() = match x with | Stack (_, s) -> s | _ -> failwith "empty stack"
   member x.Push a = Stack(a, x)
member x.IsEmpty = x = Empty
(Well, I'd probably just use a list in most cases.) But interestingly, he has an All function, which returns a sequence of the entire stack. Chris suggested using sequence expressions and then recursively calling the function:
member x.All =
    match data with
        | Empty
-> Seq.empty
        | Value (v,n)
            seq {
yield v
yield! n.All }
This is pretty nice as far as syntax goes. For some reason, I wanted to see how it'd look without the recursion (which needs to generate a new enumerator, unless the compiler is doing some wicked awesome stuff, which wouldn't surprise me). Here are some of the things I came up with:
member x.All1 = 
let until f = Seq.generate (fun () -> ref x) f (fun _ -> ())
   until (
fun cur -> match (!cur) with 
                        | Stack(v, s)
-> cur := s
                                         Some v 
                        | _
-> None)
Seq.generate continues calling the function until None is returned, so this provides the loop termination. Another similar approach:
member x.All2 =
let until f = Seq.generate (fun () -> ref x) f (fun _ -> ())
      until (
fun cur -> try (!cur).Peek()
finally if not (!cur).IsEmpty then cur := (!cur).Pop())

Since Peek already returns 'a option, we can use it directly. The problem is that we need to update cur to cur.Pop
and then return a value. The try/finally works, but the whole deal still doesn't seem very elegant. Sequence expressions allow us to yield:
member x.All3 =
let cur = ref x
while not (!cur).IsEmpty do
          yield (!cur).Peek()
do cur := (!cur).Pop() }
      |> Seq.choose(
fun x -> x)

I dislike this one. Because we're not doing the pattern match ourselves, we end up yielding 'a option. But None is never valid because we guard on IsEmpty. This makes us stick a Seq.choose on with an identity function to strip off the Some. [Side note, is there no built-in identity function?] Bringing the match into the seq fixes the issue, but the code is pretty long:

member x.All4 =
let cur = ref x
while not (!cur).IsEmpty do
          match (!cur).Peek() with
                      | None
-> do ()
                      | Some v
-> do cur := (!cur).Pop()
yield v }

 I think what bothers me the most here is that the while and match are redundant. The None case will never be matches because we guard on IsEmpty. Moving that into a separate function gives:

member x.All5 =
      let v = function Stack(vl, _) -> vl | _ -> failwith "dont call on empty"
      let cur = ref x
while (!cur) <> Empty do
          yield v (!cur)
do cur := (!cur).Pop() }

I prefer All5 to All4, but still think All1 or All2 are nicer. (Chris's original is best as far as I can tell.) How else can this be done?

Edit: I lost sight of one of the principals of functional programming: Composition. Here's a simple update to All5 that, IMHO, vastly improves it:

member x.All6 =
let cur = ref x
let toVal = function Stack(v, _) -> v | _ -> failwith "dont call on empty"
      let next () = try toVal (!cur) finally cur := (!cur).Pop()
while (!cur) <> Empty do yield next () }

Every line builds up and you don't have to keep its details "active" in your mind. This makes the sequence expression (which is the driver of the algorithm) easy to verify. And again, to clarify, in a real system I'd probably use what Chris suggested since it's the nicest syntax. The other versions are only seeing what it looks like if we toss recursion and use a reference cell.

Code | FSharp
Saturday, August 16, 2008 4:09:49 AM UTC  #    Comments [0]  |  Trackback

# Friday, August 15, 2008
Typing string IDs

I just read these two posts:

And that reminded me about something we recently did. One system we're working on uses a lot of string identifiers for many different types of objects. There are many, many of these stored and passed around, so keeping things efficient was of high concern. 

The downside of string IDs (really, using any common type as an ID) is that it's legal to pass any primitive of the same type. Strings and integers abound, both as IDs of other classes, as well as general use. So it's not unimaginable that someone could pass the wrong parameter some where. This could lead to runtime crashes or unexpected results (if the ID is actually a real record of another class of object). Finally, using common types for IDs reduces usability. The signature "public void Delete(int id)" leaves a lot to be desired.

We wanted to hit all these issues, in addition to keeping things simple. There are times when untyped data needs to be converted, and this should be easy and clear. We wanted to avoid having to define new types when we had new classes of objects to identify It is also customer-visible code, so C# is used.

Using a reference type was unacceptable, because it'd add at least 12 bytes overhead (I think more on x64). Using a struct fixes this, in addition to dealing with silly nullability issues. [If a type can be null, it should always be explicit. C#'s "references types can be null" makes this hard.]

The end result was quite simple. Wrap a string in a structure so equality and hashing pass through. But, take advantage and remove case/cultural sensitivity (since in many systems, data IDs are not case sensitive). Provide explicit conversions so you can easily convert to and from strings, but never by accident. (If the conversions were implicit, you're back in the starting point.) Finally, add a generic parameter that is never used. The generic parameter gives you distinct types without having to define them. Now the APIs can look like:

    public void Delete(Id<Product> id)...

    Dictionary<Id<Group>, List<Id<User>>> members...

When you do have hardcoded IDs, as the blog entries I mentioned do, you can convert easily: (Id<User>)"Admin". Nulls are treated as empty, all the time (empty may be a valid value anyways).

When a truly optional ID is needed, use nullable types: "Id<Whatever>?". This fully captures how values are handled. This is vastly better than "It's a reference type, so maybe null is allowed. Or maybe null will crash. Empty string might be considered null, or maybe empty string means optional." With explicit nullability, the type system says it all.

The best part is that there should be pretty much no overhead. I'd expect the equality functions to be inlined, and there's no memory overhead, since the struct is simply a string reference.

Here's the class.:
public struct Id<T> : IEquatable<Id<T>>
    public Id(string name) {
        this.name = name ?? "";
    readonly string name;
    public static explicit operator string(Id<T> x) { return x.name ?? ""; }
    public static explicit operator Id<T>(string s) { return new Id<T>(s); }

    public override bool Equals(object obj) {
            !(obj is Id<T>) ? false :
            ((Id<T>)obj) == this;

    public bool Equals(Id<T> other) {
        return other == this;

    public override int GetHashCode() {
        return (name ?? "").GetHashCode();
    public override string ToString() {
        return name ?? "";
    public static bool operator ==(Id<T> a, Id<T> b) {
        return StringComparer.InvariantCultureIgnoreCase.Compare(a.name, b.name) == 0;
    public static bool operator !=(Id<T> a, Id<T> b) {
        return !(a == b);
I'd be interested in seeing a more generic, yet very simple, solution: one that doesn't rely on the underlying type to be string, but still provides all the same functionality. I don't think it's possible, since there's no way to get a generic constraint that'd allow similar handling of "string" and "int?". Additionally, structs can't inherit, so you'd end up using "Id<string, Product>" everywhere, which is far from elegant.
Friday, August 15, 2008 7:39:11 PM UTC  #    Comments [8]  |  Trackback