The problem with Haskell for .NET is that the produced executables are usually very slow. Good optimizing compiler like GHC has better chance to produce code with reasonable performance. The major problem with YHC is that it still doesn't have strictness analyzer. The consequence is that the produced .NET code creates lots of unnecessary temporal objects. Cheers, Krasimir On 12/13/06, Neil Mitchell wrote:

Hi

Yhc also has a .NET generating capability, just pass the -dotnet flag.

http://haskell.org/haskellwiki/Yhc

Thanks

Neil

On 12/12/06, Monique Monteiro wrote:

...

Hi Justin,

I've runned a research project about this topic (in fact, it was the subject of my MSc dissertation). Please see the Haskell.NET Project (http://www.cin.ufpe.br/~haskell/haskelldotnet). We have compiled a subset of the Haskell language to .NET, but we still don't have an available release (we don't support the full Haskell prelude yet). The compiler is an extension to GHC.

In the future, we intend to provide full interoperability with .NET in this way. There are some interesting references in the website about our compilation strategies.

If you need further information about the project's status, please contact Prof. André Santos (alms@cin.ufpe.br) and/or Guilherme Avelino (gaa@cin.ufpe.br).

Best regards,

-- _____________________________________________ Monique Monteiro, MSc http://www.cin.ufpe.br/~mlbm http://thespoke.net/blogs/moniquelouise/default.aspx monique@qualiti.com.br +55 81 34198137 Project Manager Recife Microsoft Innovation Center _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 12/13/06, Neil Mitchell wrote:

Hi Krasimir,

...

to produce code with reasonable performance. The major problem with YHC is that it still doesn't have strictness analyzer.

It does, or rather Yhc.Core does (see Yhc.Core.Strictness - http://www.cs.york.ac.uk/fp/yhc/snapshot/docs/Yhc-Core-Strictness.html). This was only done a few weeks ago, so the .NET translator has no benefit from it.

And strictness is not the biggest problem, a complete lack of any optimisations is, but I'm working on that one too!

It is great to hear that. Of course an optimiser will be beneficial too but I guess that even the benefit that the code generator can have from the strictness analyzer will make huge difference. Cheers, Krasimir

On 12/13/06, Krasimir Angelov wrote:

The problem with Haskell for .NET is that the produced executables are usually very slow. Good optimizing compiler like GHC has better chance

I don't really want something that compiles Haskell to the CLR, though that would be great eventually. Even something that just interoperates with .NET is good enough. The Hugs98.NET project seemed to extend the FFI to be able to work with .NET - is that capability available somewhere still? Justin