[m-dev.] Language interface improvements

[Peter Schachte]

> Zoltan Somogyi, you wrote:
> > The extended external language interface is really a collection of smaller
> > subtasks, and the different subtasks are probaly best approached differently.
> [...]
> > One of the tools I expect the summer student to write would parse C prototype
> > declarations and produce both the declarations and the code for the Mercury
> > predicates required to access these. One problem here is the treatment of
> > non-builtin data types such as structures; how should these be accessible
> > from Mercury?

The most convenient way to do this would be to have Mercury treat C structs
as Mercury terms.  That is, you can create a struct in C and pass it to
Mercury, which treats it as a Mercury term of a corresponding type. And vice
versa. This would, of course, entail breaking the assumption that every term
argument is a single word (which would be a good change anyway for floats
and small enums, and maybe other things as well).  Handling unions would be
a bit of a problem (but then, unions are a bit of a problem in C, too).  If
the user could specify how to distinguish the cases of the enum, Mercury
could treat it as a discriminated union.  Working out the details of this
would be even more work. 

It's probably a big job, perhaps too big for what you have in mind, but it'd
sure be nice.  (What's that I hear?  Is that Tyson screaming in terror?) 


-Peter Schachte			| Politicians are the same all over. They
pets at cs.mu.OZ.AU		| promise to build a bridge even where there is
http://www.cs.mu.oz.au/~pets/	| no river. -- Nikita Krushchev 
PGP key available on request	|