On 02-Aug-2000, Erik Meijer <[EMAIL PROTECTED]> wrote:
>
> > > The plan is to have the release out the door by September 1st.
> >
> > Will that release support Haskell, or just Mondrian?
>
> 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?
> > 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.
>
> As I explained the translation has to implement the features that the
> .NET runtime does not provide itself. Hence, must implement lazy evaluation
> and you must implement currying yourself.
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.
> The same is true for Mercury. Since the .NET runtime does not support
> backtracking, you are simulating that by passing extra continuation
> arguments around.
That's true. However, the way we map nondeterminism is a quite
high-level approach, suitable for direct use from other languages.
Note that in our original compiler for Mercury, which goes via GNU C,
we handle nondeterminism using a low-level approach where we implement
our own virtual machine on top of C. But for targetting the .NET
platform, we completely rewrote the compiler back-end, using a new
and much higher-level approach that leads to a much more direct
mapping.
The approach that you've taken to implementing currying using your own
argument-passing stack looks to me like a fairly low-level approach.
As a programmer, if I want to interface to Haskell code, I'd prefer
it to be as high-level and as automatic as possible; I'd rather not
write any glue code if I can avoid it, and if I do have to write glue
code, I'd much rather it if I didn't have to muck around with
low-level details like pushing arguments on stacks -- that's what
compilers are for.
> > 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.
>
> Not true. It is extremely easy to interoperate with other languages.
> Yes, you do have to do some marshalling and unmarshalling, but again,
> you *must* do that to match up the semantic differences between
> the language of the caller and the callee.
Not necessarily. There need not be any such semantic differences.
Certainly in many cases there will be, and in such cases marshalling
will be required, but in many other cases the language that you
are interfacing with will have some direct equivalent of all of the
features used by the function that you are exporting.
For example, if I have a Mercury function
:- func foo(int) = int.
then this could correspond directly with the ghc function
-- this makes use of ghc's unboxed types extension
foo :: Int# -> Int#
If I want to call the Mercury function from ghc code, using that prototype,
then ideally there should be no need to write any wrapper, glue code,
or interface definition.
Of course when calling code that uses unboxed types from code that
uses boxed types, you need to write some code to unbox the values, and
that could quite fairly be called glue code. But that glue code is
not language interop glue code, it is boxed type - unboxed type glue
code. As a ghc programmer, I don't need to know anything about the
properties of the implementation or of the language that I'm
interfacing with to write such glue code, I just need to know about
the ghc language, specifically ghc's unboxed types.
> To call into Haskell, you use a trivial wrapper function that pushes
> the arguments on the stack and calls the underlying Haskell function.
> Or you call the function directly trough its fast entry point.
Well, these fast entry points definitely sound like an improvement.
They're not mentioned on the Mondrian web page whose URL was posted
earlier in this thread. Are these something you're planning to
include in the Sept 1 release?
> > 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.
>
> Come on Fergus! You will never achieve interoperability on that level
> except when your semantic domains match exactly or when you have an
> extremely complicated intermediate language. For example, most
> languages don't make the distinction between values and computations
> as Haskell does, and I don't expect or want for example VB programmers
> to do that either. But it does mean that whenever I call a VB function,
> I must write a little glue code to compensate for the difference in
> semantics. The same is true for calling nondeterministic or multi-moded
> Mercury predicate.
No, it's not true. You can call multi-moded or nondeterministic
Mercury predicates directly from other .NET languages without any glue
code.
For multi-moded procedures, the mode number is part of the IL function
name, so you just pick which function name you want to call, and call it.
For nondeterminstic procedures, the caller needs to pass a success
continuation callback function, which will get called once for each
solution. But that's not glue code for the purpose of handling
language inter-op; that's just the way in which the interface is
exposed. If I were writing code in C that needed to use backtracking,
I'd do it the same way, even if there was no Mercury code involved at
all.
(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.)
> > For example, which of the various CLS (Common Language Specification)
> > categories does the Haskell and/or Mondrian implementation comply with?
>
> Aha, finally you hit a real issue. To be a CLS extender would require
> a lot of language extensions to a lot of languages, even to OO languages
> like Java! But for Haskell the situation is even more severe.
Indeed. But will your implementation even meet the specification
for a CLS consumer?
> > 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.
>
> That is right. The thing here is to use the "code behind" style ASP pages.
Could you elaborate? Or could you give a pointer to where we could
find out more about "code behind" style ASP pages?
--
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.
