> Does anyone know where there is some information on Haskell integration
with
> the Microsoft NGWS runtime, which provides
> cross language integration and a common system for memory managment,
library
> functions etc.
>
> I am curious to see if the haskell integration is a good fit or a graunch
> (square peg into a round hole).
>
> I know some work is being done on haskell in this regard, but exactly what
I
> do not know.

The plan is to have the release out the door by September 1st. The
translation is quite elegant IMHO, it only encodes those features that
Haskell has, but the .NET runtime lacks, that is lazy evaluation and
currying (what else can you expect). You can find the essence of the
translation on http://www.cs.uu.nl/~erik/MondrianDescription.html. Since C#
(our target for the .NET framework) lacks inner classes, we have to lift out
inner those as well, which is not needed if you compile to Java (which is
the main reason that the Java backend is not to bytecodes). But then when
you compile to C or assembler you have to do the same, there you have to
encode even more of Haskell's features because the target language supports
nearly nothing.

As we demo-ed at the PDC, we have full bidirectional interop between Haskell
and other .NET languages. Since Haskell does not have a notion of class (in
the OO sense), extending a class is a bit of a hack obviously. You have to
write the class in C# say, and let its methods call the Haskell functions
that really are the method implementations. Again, what else can you expect.
The design of all this is the same as in Lambada (the Haskell-Java Native
Interface binding, will be presented at the Haskell workshop). The
experimental language Mondrian is an experiment to design a Haskell dialect
that does directly support OO-like features, ie a light-weight lazy
functional scripting language for .NET components.

Overall, I find the .NET compiler ***much*** cleaner and easier to use than
Lambada, thanks to the fact that the interop is at a much higher level, ie,
hardly any need for marshalling and unmarshalling, no need to allocate
memory etc. We have not optimized for speed so I cannot say anything
sensible about that. I guess that we can gain quite a lot of speed by
compiling into IL instead of C# and use tail-calls and value types.

The fact that there is a common runtime is a really great thing. In the old
days for example, you had to implement your own so called ActiveX scripting
engine to host Haskell programs in HTML pages, ASP pages, or WSH. Now you
only have to target to IL and get those goodies already paid for, ie you can
write ASP+ pages in Haskell, COBOL, Mercury, Perl, Phyton, APL, Smalltalk,
Scheme, Component Pascal, Eiffel, Oberon, ... (The corresponding thing for
Java would be that if I compile Haskell to Java, I get Haskelletes already
paid for).

Hope this helps, and if you have more questions feel free to ask me.

Erik

BTW C# is a pretty cool language too.


Reply via email to