I think that using an existing back end of an optimizing compiler such as GHC is more promising than targetting Java, C# or other imperative/OO language. GHC already does a lot of work to achieve a good performance. So, if you generate Java code, you'd have to do a lot of work to get good performance in the final code, 'cause of the huge semantic gap between Haskell and Java. Also, you don't have any control on the JVM internals, such as GC and other things. However, if you want portability or easy access to object-oriented APIs, generating Java code (or .NET code, for interoperability with other languages) should be your choice. Cheers, Monique

Gentlefolk:

Help. I need support for a technical argument: why going to an intermediate form for an existing functional back end like Haskell really, truly is better for implementing a functional language than is going to an intermediate form like the Java intermediate form and re-doing all the various specialized mechanism needed to support a true lazy functional language. In other words, I need a pithy paper or book chapter that will convince someone unfamiliar with functional languages that Functional Back Ends Really Are Different --- no, Really Truly Different. Something on the order of Why Functional Programming Matters, but for the implementor of the language, not the programmer.

Any pointers to a good article or book chapter that might help? I keep saying that this bookkeeping is a BIG task, but they keep saying they know they can "handle" it. Pithy comments? Staff year estimates? Horror stories?

Thanks, anyone.

Dave Barton

-- __________________________________________________________ Monique Monteiro, MSc MCP .NET Framework 2.0 / SCJP / IBM OOAD Project Manager Recife Microsoft Innovation Center +55 81 34198137 http://www.cin.ufpe.br/~mlbm http://thespoke.net/blogs/moniquelouise/default.aspx monique@qualiti.com.br MSN: monique_louise@msn.com