[m-rev.] Re: [m-dev.] for discussion: pragma foreign_import

[Peter Ross]

Fergus wrote:
> On 05-Dec-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > On Wed, Dec 05, 2001 at 05:57:07PM +1100, Fergus Henderson wrote:
> > > > Index: reference_manual.texi
> > > >
===================================================================
> > > > RCS file:
/home/mercury1/repository/mercury/doc/reference_manual.texi,v
> > > > retrieving revision 1.229
> > > > diff -u -r1.229 reference_manual.texi
> > > > --- reference_manual.texi 4 Dec 2001 11:11:59 -0000 1.229
> > > > +++ reference_manual.texi 4 Dec 2001 13:43:47 -0000
> > > > @@ -5009,7 +5009,10 @@
> > > >  @node Data passing conventions
> > > >  @section Data passing conventions
> > > >
> > > > -Each backend will have its own conventions for passing data.
> > > > +For each backend,
> > > > +we explain how to map a Mercury type to a type on the backend.
> > > > +We also map the Mercury parameter passing convention
> > > > +to the backend parameter passing convention.
> > >
> > > s/backend/back-end/g
> > >
> > > Also the conventions should be language-specific,
> > > not back-end specific.
> >
> > I am not so sure about this.
>
> I am.
>
> > Why should the Managed C++ convention be different to the C convention?
> > MC++ is just a superset of C.  It is different because we do different
> > things on the different backends.
>
> It is different due to histerical reasons.  If we were to redo the C
> interface again, it might look more like the Managed C++ interface.
> The reason we do different things with Managed C++ than we do for
> C is mainly because we weren't hampered by backwards compatibility
> issues when designing the Managed C++ interface.
>
I think backwards compatibility is a bit of a non-issue, as it is
already addressed by the following comment in the Mercury reference
manual

  (Note: it would in fact be better for each Mercury type to map to a
  distinct abstract type in C, since that would be more type-safe, and
  thus we may change this in a future release.  We advise programmers
  who are manipulating Mercury types in C code to use typedefs for each
  user-defined Mercury type, and to treat each such type as an abstract
  data type.  This is good style and it will also minimize any
  compatibility problems if and when we do change this.)

> Suppose we implement a C interface for the .NET back-end.  Should it
> use the same conventions as the MC++ interface for the .NET back-end,
> or the same conventions as the C interface for other back-ends?  The
> answer has to be the latter, because that is the only answer which
> will ensure portability of code which uses the C interface across
> different back-ends.  Therefore things should be language-specific,
> not back-end specific.
>
I see your point, but is this goal achievable?

Say someone implements a C# compiler for the JVM.  Will it even be
possible for us to map the current scheme onto the JVM?  It is not so
difficult to do C interfaces because of their lack of type safety.
However for the C# interface and the lack of typedef like behaviour I am
not so sure that this will be so easy.

Ok let me think this through.

The real problem is to generate an interface for each foreign language,
where the interface is independent of the backend.  This implies, to me,
that the only types that we can safely assume are available for every
backend are int, float, char and string.  For everything other Mercury
type we will need to have one type name which is the same for every
backend.

This is trivial to do for the C backend.  We can just use typedefs, but
what about strongly typed backends which don't support typedef like
behaviour (hmmm can anyone think of one :) ).  Provided the backend
provides another mechanism for relating two types together (ie object
inheritance :) ) then I imagine we could support this scheme without
an efficiency problem.  I am just worried about whether we would ever
need to do a downcast.  For backends which don't support any of the
above then I guess you will just need to marshal the arguments at each
foreign interface boundary, which could be terribly inefficient.

Ok that problem looks solvable, a lot of work but solvable, summer
student anyone?

Ok now we have an abstract name for each type, we also need to be able
to access the terms which make up a type.  Currently that is both
backend and data representation specific.  This suggests to me that we
have to have a mechanism which exports a type for use by a foreign
language, and then you use this exported interface to access the type as
required.

Another summer student (or possibly the same one)?

So in summary, I think it is possible to use the same code on multiple
backends but it is a lot of work and the current documentation reflects
what you have to do now, so I am hesitant to change it apart from
putting a big XXX this is all going to change!

I am back in Australia for 6 weeks in two weeks time, would it be
possible to discuss all of this in more detail then?

Pete
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------