Functional Languages and .NET Mappings

Ian blogs about F#. What caught my eye was this:

So I installed F#. I had been putting it off, because one of my many projects involves writing a .NET compiler for a language whose native behaviour doesn't look like a great fit for the CLI. (I'm particularly interested in what happens at the component boundary where you might have to meet other languages.)

The last sentence is the key (and I'm also wondering what language Ian is referring to, but that's not relevant right now). I spent a lot of time a couple of years ago looking at other languages that were targeting the .NET runtime, and where it would usually get messy is when you tried to use an assembly generated by one of these compilers in C# or VB. Check out Chapter 6 of my CIL book, or, if you like free stuff, check out this article I wrote on .NET languages. The way Eiffel exposed its multiple inheritance or the way Oberon created its active objects or the freakiness you'd see from a SML.NET was a fun trip. It's not that these compilers did things wrong per se. In the case of SML.NET, it had to do some "freaky" things to get the functional constructs correct, although I had some concerns about what Eiffel and Oberon did. Sometimes, mapping a language to a runtime requires creativity, and when another language tries to use the binaries generated by the first language's compiler, it can feel awkward.

* Posted at 10.04.2005 08:09:29 AM CST | Link *

Blog History