> GHC supports concurrency, exceptions, weak pointers, foreign calls,
> etc, etc. All these need to be mapped onto .NET. ... GHC comes
> with a large collection of libraries of its own. These need to be
> still available in the .NET version.
I don't really agree with these points. If someone tried to support all
of this they'd be unlikely to appear out the other end of the swamp.
Having actually tried both ways myself, I'd suggest that GHC is simply
not the right starting point for a Haskell.NET compiler. Much better to
start a fresh compiler, essentially from scratch, with a suitable
selection of optimizations, language extensions, library features and
interop extensions given the platform and kind of programming you're
aiming to support. If you look at history successful compiler projects
do not tend to some out of attempts to graft large code bases for
alternative purposes (unless you've got loads of resources to throw at
the problem).
Cheers,
Don
-----Original Message-----
From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED]]
Sent: 31 May 2002 15:31
To: Don Syme; D. Tweed
Cc: Paul Hudak; haskell
Subject: RE: [Fwd: F#]
| Idle curiosity: which aspects of the Haskell language are the
| ones that make it complicated -- e.g., long-time stuff like
| lazy evaluation, typeclasses & inferrence, etc or newer stuff
| like functional dependencies, etc or something else entirely
| -- and do they only make it complicated in the context of the
| .NET architecture or in any implementation?
General remarks about targetting .NET from GHC.
* There is no reason in principle why one can't write a back end
for GHC to generate .NET IL.
* Generating *verifiable* IL is noticeably harder: you have to
take much more care; to deal with parametric polymorphism you
need Generic IL, which isn't "out" yet; and even then, higher kinded
type variables are a serious problem. Being verifiable almost
certainly requires some runtime checked type casts, which hurt
performance -- and reducing them to a minimum complicates the
compiler.
* My conclusion: best plan is to generate unverifiable IL, and
run it unverified. Situation is then just like an existing code
generator:
you have to trust the compiler. But it's fast and it's much simpler.
* The resulting code will still run quite a bit slower than GHC-complied
code. So why would anyone want to use it? Presumably, to get access
to the .NET libraries. So that has to be very convenient. Tools are
needed to read .NET library meta-data and generate impedence
matching glue to make them easily callable from Haskell. Haskell needs
some new 'foreign import' stuff to make it easy to call the libraries.
There's a big design space here about how much to extend Haskell
to make calling .NET convenient.
* GHC supports concurrency, exceptions, weak pointers, foreign calls,
etc, etc. All these need to be mapped onto .NET. Some might not
fit well; for example, Concurrent Haskell assumes extremely lightweight
concurrency, whereas .NET threads are OS threads; and asynchronous
exceptions might be tricky too.
* GHC comes with a large collection of libraries of its own. These
need to be still available in the .NET version, so the .NET
implementation
of GHC needs to be pretty fully-featured (because the libraries use
a lot of features).
What all this means is that GHC.NET is a lot more than just a code
generator. That is, I think, what Don meant when he said that
GHC is complicated. (In our defence, it is the very fact that GHC is a
rich system that makes it useful. Its complexity is not gratuitous.)
Part of my reason for writing this is to encourage anyone out there
to take up the challenge. There's nothing too difficult -- it's "just
work".
Simon and I don't have immediate plans to do anything about this,
but we'd be delighted if someone else did.
Congratulations to Sigbjorn to doing a great job with Hugs.
Simon
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
