[m-dev.] foreign type syntax

[Tyson Dowd]

On 25-Oct-2001, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> > 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.

Yes, this is already automatically generated for the IL case.
I just want to make sure the syntax is extensible to most of the cases
we need.

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

Ok, that's fine.  If required, the backend specific part could
optionally leave out the name.

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

Yes, and it can be pretty much extended as required without impacting on
anything else.

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

Nobody said we would support the entire language...  
We are certainly not trying to handle parameterized types yet.

There are encodings out there for (almost) the entire C type system to
be encoded in the type system of ML, so I think if we wanted to we could
handle anything we wanted to (we don't have to encode using the type
system of Mercury, we can use terms instead).

foreign_type only declares a (mostly) abstract type in
Mercury, the actual definition of the type only matters when we want to
generate code.  So the fact that the target system has crazy type
semantics shouldn't cause too much alarm, as the types might as well be
abstract as far as the Mercury programmer is concerned.

The main benefit foreign_type gives is that when you start interfacing to
foreign language code you don't have to do casts or uncasts -- it is as
if the Mercury compiler already knows about your type the same way it
knows about MR_Integer or MR_Float. 

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------