[m-dev.] foreign type syntax

[Fergus Henderson]

On 01-Nov-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> Of course the user is going to have to be very careful about such
> things.
> 
> If you write:
> 
> :- pragma foreign_decl("C", 
> "
> 	typedef struct foo {
> 		int x;
> 	} bar;
> ").
> 
> :- pragma foreign_type(bar, c("bar")).
> 
> you cannot expect the type parser to do much.

This is basically another typedef problem that is very similar to the
typedef problem that I mentioned earlier:

> > But regardless of whether it is done by inventing new Mercury syntax
> > for C types, or by writing a parser for C, it is going to be very
> > difficult to handle types such as `FILE' or `pid_t' which are defined
> > as typedefs in header files.  The problem is that it is hard for the
> > Mercury compiler to find the C header files for this system, and these
> > may not even be in standard C syntax.

And so *for C*, as I said earlier,
I don't think we should try to do a type parser.

> > So the only reasonable way I can see of handling typedefs such as those
> > is to not try to interpret anything about the structure of the C type.
> > That can be done using the approach I described earlier (representing
> > foreign types as `MR_Box', i.e. `void *', and boxing/unboxing them in
> > the C wrapper functions).

With this approach, your example code using typedef would work fine.

> > For the .NET back-end, we could use IL or C#/MC++/... syntax.
> > In the short term, we treat these as uninterpreted strings,
> > which means we'd need to require the user to give
> > `pragma foreign_type' declarations for both IL and
> > whatever other foreign languages these types are used with.
> 
> Since you cannot know in advance which foreign languages a type is used
> with , you either demand all of them, or you throw exceptions if one is
> demanded but not available.

s/throw exceptions/report a compile time error/

> The idea with the .NET backend was to try to invent syntax that was
> pretty close to the Mercury syntax for foreign language types (e.g. what
> that type would map into in Mercury).  This was trying to go along with
> the general idea of .NET -- you don't necessarily have to learn a
> foreign language to interface with it.  

Hmm.  A nice idea.

I guess the trouble is that to make this idea work fully, we'd need to
extend Mercury with something corresponding to every .NET construct.
"Mercury#", anyone? ;-)

If we then do the same for every other system that we want to interface
with (Java, C, C++, etc.), then I guess we'd end up with "Mercury#++$@!!",
which is also what I might starting saying at that point ;-) ;-)

-- 
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
--------------------------------------------------------------------------