Erik Meijer <[EMAIL PROTECTED]> wrote:
^^^^^^^^^^^^^^
> [someone wrote:]
> > 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.
Will that release support Haskell, or just Mondrian?
> The translation is quite elegant IMHO,
I'm afraid I have to disagree on that point. Basically you translate
quite a few things by implementing your own virtual machine on top of
the .NET runtime. For example, argument passing is done with explicit
pushes and pops on your own virtual machine stack, rather than by
using the .NET runtime's argument passing. This approach makes the
compiler is fairly simple, but the generated code is not what _I_
would call elegant.
> it only encodes those features that
> Haskell has, but the .NET runtime lacks, that is lazy evaluation and
> currying (what else can you expect).
Don't you currently encode tail calls too? And what about
type classes and polymorphism?
Also, as I understand it, Haskell/Mondrian programs that don't make use of
currying -- e.g. those in which all functions have only one argument --
still get encoded, rather than being mapped directly. So the encoding
is not done in way that you only pay for it when you use those features.
This makes interoperability with other languages more difficult.
> As we demo-ed at the PDC, we have full bidirectional interop between Haskell
> and other .NET languages.
Hmm, the "full" adjective here sounds like it might be a bit of an
overstatement. Does that mean that I can call Mercury code from
Haskell, have it all statically type checked, and not have to write
any additional interface definitions or glue code? Including
procedures which are polymorphic and/or use type classes?
If so, I would be very surprised! I think the current level of interop
supported is still a LONG way from what I would describe as "full"
interoperability.
So, could you elaborate on what sense you mean when you say we have
"full" bidirectional interop?
For example, which of the various CLS (Common Language Specification)
categories does the Haskell and/or Mondrian implementation comply with?
> 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).
Actually that's not really true; compiling to IL is not enough.
To support ASP+ for a given language, you also need to implement a
certain API. Now my information on this is mostly second-hand,
but as I understand it, this API pretty much assumes that your
language is a fairly typical imperative language, with constructs
like loops, etc. So it is fairly easy to implement this API for
imperative languages, but not nearly so easy to implement it for
functional languages or other non-traditional languages.
In addition, I think your compiler also needs to support attributes?
P.S. My research group has received substantial funding from MS,
so my opinion on these issues may not be entirely objective.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
