Well Erik & Fergus seem to be into a "my language/implementation" is
better than yours battle ;-) while some others are confused as to
what they're talking about. Not to prolong it, but let's see if I can
clarify a few issues (ROTW: I wrote the Mondrian -> C# bit [and other
odds'n'endz])
At 6:48 pm +1000 2/8/00, Fergus Henderson wrote:
>On 02-Aug-2000, Erik Meijer <[EMAIL PROTECTED]> wrote:
> > The compiler hooks into GHC by translating Core into GOO
>> and then after some source to source transformations it
>> can spit out either C# or Java.
>
>Hmm... am I right to presume you mean that it will support Haskell?
>What about ghc's extensions, such as unboxed types? Will it support
>those?
Unboxed: from Haskell's point of view yes. Explanation: constants are
unboxed in GOO and GOO provides unboxed parameter passing. However
(ssh!) the GOO VM currently does a hidden box/unbox behind the scenes
when parameters are passed. It doesn't *need* to do this, but there
are reasons for the current choice. Depending on performance this may
get changed.
>I understand that point, but if doing that means that you need to
>implement the basic things like argument passing and procedure
>calling yourself, using your own virtual machine, rather than
>by using the underlying runtime's argument passing and procedure calling
>mechanisms, then I'd say that it is looking more like putting a round
>peg in a square hole than a good fit.
Passing arguments on a separate stack is pretty lightweight. It's
there to support currying. If you call a function with its arguments
we could use the .NET stack. Such an optimisation falls out of a
typical (well out of the one I developed and used in Massey Hope+C
anyway) usage analysis (which gives you other things as well). I
expect such an optimisation will be added as the system is developed
and more engineering (as opposed to research) is done.
<snip a lot about glue code>
>(Note that currently you _do_ need to write glue code when
>calling other languages from Mercury. But you don't need to
>write glue code when calling Mercury from other languages.
>We also plan to automate the generation of glue code when calling
>other languages from Mercury, so that you won't need to write
>any of it manually.)
Well from this it seems you have the opposite of what we have at the
moment - calling other languages from Mondrian is automatic, the
other way you currently have to write the glue. Of course it should
be done both ways - pity we're not working on the same language as we
both seem to have 50% done...
>Indeed. But will your implementation even meet the specification
>for a CLS consumer?
Almost does already I think - we don't support enumerated types or
arrays directly in Mondrian but you could call another language
function which returned them and then pass them onto other external
functions which did something to them. Otherwise you can create
objects & access the member functions, fields and properties. You can
all a method which takes unboxed values and Mondrian's boxed ones
will be automagically unboxed. It's pretty hard not to be a CLS
consumer modulo a few types.
Haskell.NET is still a work-in-progress, but's its coming along (it
uses the same code generator and runtime as Mondrian.NET)
As to those of you completely confused a quick translation guide:
.NET = JVM with support for stack allocated structures and any
language you like - provided you can make it look like Java (sorry
C#), C# = Java with all your old favourite C heiroglyphics (bet I
spelt that wrong!) and some added extras (like "const" and "read
only" modes) to help you obfuscate your code. More seriously as a
number of languages are being produced to run over .NET along with a
whole slew of libraries it provides a good platform to target your
favourite research language at (for Windows platforms at least). This
may help get your research language used (e.g. Haskell in this case).
However like the JVM it is fundamentally OO so you may need to
develop derivatives of your language designed to better interoperate
in an OO world (aka. Mondrian/Haskell# in this case) - unless your
research language is Object Pascal (produced for .NET by Queensland).
Disclaimer, as Fergus added one: I am working with Microsoft on .NET
implementation, but I run Windows 2000 on my G3 PowerBook and take it
to Microsoft with me. I'm biased on everything :-)
Cheers,
Nigel
--
--
Nigel Perry, New Zealand
