[m-dev.] foreign type syntax

[Fergus Henderson]

On 30-Oct-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> This reply kind of wanders a bit, but basically I'd like to ask -- what
> are you disagreeing with, and why.  I've tried to give my views on why I
> like the syntax I proposed.

Basically what I object to is the language complexity of your proposal.
Following this path to its logical conclusion will lead to putting the
whole C type system in Mercury as special Mercury syntax -- and the
whole .NET type system, and the whole Java type system, and the same
for every other strongly typed language that we want to interface to.

I want to find a way that avoids needing to have special Mercury
syntax for all that.

One possibility, the one which I've been considering so far, is for the
type to be specified just as a string in the foreign language and
for the Mercury compiler to treat it as just an uninterpreted string.

Another possibility is to specify the type using the Mercury type
system, by using ordinary Mercury types to encode the C / .NET / Java
type systems, in the style of Mattias Blume's ML to C interface [1].

[1] Mattias Blume.  ``No-Longer-Foreign: Teaching an ML compiler to
speak C "natively".''.  BABEL'01.

> On 30-Oct-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > What exactly do you think is "hacky" or "sneaky" about it?
> 
> Hacky: 
> 
> It's hard to maintain, hard to read, gdb will make a mess of it.
> Compare it to the alternative which has no casts to generic types, uses
> real type names on arguments, and doesn't have to switch on sizeof.

Here you are arguing on the basis of implementation complexity,
essentially.  If the choice is between complexity in the language
and complexity in the implementation, I'd prefer complexity in the
implementation.

But in any case, I don't agree with your arguments about implementation
complexity.  We need the mechanism for casting to and from generic
types anyway, regardless of which approach is taken, in order to
be able to store foreign types in polymorphically typed containers.
The difference between this approach and what you suggested is just
where the boxing/unboxing operations go.  So I don't buy the argument
about maintainability.

> Sneaky:
> 
> You allocate memory behind the programmer's back

True.  But the Mercury compiler will do exactly the same thing when you
put non-word-sized data structures into polymorphically typed containers.

It's a drawback, but it's not a new one.

> What are you trying to convince me of?  I'm starting to lose the point
> of this discussion.
> 
> My understanding was you disagreed with the idea of having an encoding
> of the type name in Mercury, and so far your reasoning seems to be "you
> don't need it if you do things this way".
> 
> Is that right?

Right.  And I think trying to encode the whole of every other language's
type system in Mercury will add a lot of complexity to the language.
So I want to avoid that.

> If so I'm happy to allow that as an option (exactly the
> syntax you propose is fine), but I'd like to in parallel experiment with
> a term syntax for specifying types so the compiler can possibly do a
> better job.  

The trouble with that path is that it's very easy to add complexity,
and very difficult to get rid of it once it has been added.

> > For the strongly-typed backends, the user can specify the appropriate type
> > name for the target language in the `pragma foreign_type' declaration,
> > and the Mercury compiler can just emit that type name in the generated
> > target code.
> 
> IL uses a different syntax to C# which has different syntax to MC++ and
> so on.  
> 
> Is your suggestion that the user provide one type name for each
> foreign language?  

Yes.

> This would be somewhat difficult if we ever decided to use a
> programmatic interface on the strongly typed backends (e.g.
> .NET's Reflection.Emit or a java compiler's backend).

True.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  | "... it seems to me that 15 years of
The University of Melbourne         | email is plenty for one lifetime."
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- Prof. Donald E. Knuth
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------