[m-dev.] foreign type syntax

[Tyson Dowd]

On 25-Oct-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> On Thu, Oct 25, 2001 at 10:13:57PM +1000, Fergus Henderson wrote:
> > On 25-Oct-2001, Tyson Dowd <trd 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. 
> > 
> > What happens if the foreign language type doesn't fit in a single word?
> > Will the Mercury compiler automatically box/unbox it, like it does for `float'?
> > 
> > > Currently the syntax is:
> > > 
> > > :- pragma foreign_type(xmldoc, 'System__Xml__XmlDocument', il("System.Xml")).
> > > 
> > > This defines a new Mercury type "xmldoc", which is defined to be the
> > > same as the type System.Xml.XmlDocument in the IL backend, which can be
> > > found in the assembly System.Xml.
> > > 
> > > This syntax is a bit broken, but it helps us establish what has to be
> > > covered by an improved syntax:
> > > 
> > > We must specify 
> > > 	- the name of the Mercury type
> > > 	- the name of the foreign type
> > > 	- the backend(s) to which this mapping applies
> > 
> > Why do you say "backends" rather than "languages" here?
> > 
> See answer below.
> 
> > 
> > > Finally, I'm still not sure about what to do about namespace nested
> > > names.  System__Xml__XmlDocument is a bit long, but the idea is that
> > > it just uses Mercury's nested module naming system, so when we switch to
> > > "." we can just use "." instead.  So I guess it will be nicer in future.
> > 
> > I think it would be nicer to just use whatever syntax the foreign language
> > uses.
> >  
> On the IL backend, there is no language as such.  This type name might
> need to be used in one or all of IL code, Managed C++, C# and possibly
> any other IL targetting language we decide to foreign_proc enable.
> 
> So in keeping with the spirit of the IL backend, you should represent
> the name as appropiate in Mercury in this case using __ as the
> namespace seperator.
> 
> However on all the other backends, you may want to represent it how that
> backend does.

What about the asm backend?  It doesn't have a syntax for types.

If you specify the types using C syntax, you are going to have a bit of
a hard time marshalling them to and from asm (you won't know how to
generate type specifications in gcc's tree representation without
parsing the type specifications).

But if you specify types using Mercury syntax, you can so this just
fine, and generate both C an gcc tree representation type.

I wouldn't be shocked if you could hack around this by using lots of
hacky casts and some sneaky interfacing code, but it might be nice if
you don't have to...

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