[m-dev.] foreign type syntax

Peter Schachte schachte at cs.mu.OZ.AU
Thu Oct 25 13:10:50 AEST 2001


> We propose adding a foreign_type pragma, which allows you to define a
> Mercury type as being equivalent to a foreign language type. 
> It might be optimistic of me, but I think it might be worthwhile asking
> for input on the syntax.

For once, I don't think syntax is terribly important.  Firstly, I don't
think people will write these too often.  Hopefully, there'll be bunches of
them in the library.  Secondly, where many are needed, I expect eventually
people will write little programs to translate from the foreign language to
the appropriate Mercury syntax.

> We must specify 
> 	- the name of the Mercury type
> 	- the name of the foreign type
> 	- the backend(s) to which this mapping applies
> 	- we may need to specify additional information about the
> 	  foreign type (assembly name/library name)

I don't think you'll always need the name of the foreign type.  For C, the
foreign type may not have a name, as it may be an unnamed part of a named
struct or union.

> Other requirements are
> 
> 	- the name of the foreign type might be structured
> 	  	- it may have a namespace component
> 		- it may include type constructors such as * or
> 		  class/struct/enum
> 	- the name may need to be translated into other "backends" for
> 	  foreign language interfacing (e.g. into MC++, IL and C#, or
> 	  into C as well as gcc's syntax tree).
> 	- the name of the type may be different for each backend
> 	- additional information is backend specific
> 
> This indicates we should probably try something more like:
> 
> :- pragma foreign_type(xmldoc, il("System.Xml", 
> 	class('System__Xml__XmlDocument'))).
> :- pragma foreign_type(xmldoc, c(c_ptr(struct('xmlnode')))).

This looks good to me.  Each language will have its own specification for
what should be in the second part.

> Any comments at this stage?

1.  Bravo.  This will be a Very Good Thing.

2.  This is going to take a lot of work for each langauge you want to handle.
    For example, you'll run into problems with C because it doesn't
    distinguish between a pointer to a thing and a pointer to an array of
    things.  Come to think of it, how are you going to handle arrays at all?
    And indiscriminate unions?

-- 
Peter Schachte              Any man who is under 30, and is not a liberal,
schachte at cs.mu.OZ.AU        has not heart; and any man who is over 30, and
www.cs.mu.oz.au/~schachte/  is not a conservative, has no brains.
Phone: +61 3 8344 9166          -- Winston Churchill 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the developers mailing list