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

[Fergus Henderson]

On 06-Dec-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> 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:
> >
> > > 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
> 
>   ... We advise programmers
>   who are manipulating Mercury types in C code to use typedefs for each
>   user-defined Mercury type ...

I'm not too worried about breaking backwards compatibility in the abstract
sense, so long as things continue to work, but the reality is that we
have a lot of code in the Mercury distribution that would need to be
modified if we change the C interface.

Anyway don't forget the other important hysterical raison -- inertia.

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

I believe so.

> Say someone implements a C# compiler for the JVM.  Will it even be
> possible for us to map the current scheme onto the JVM?

Sure.  Currently we generate IL code, but it would be easy enough for
us to generate C# code instead.  Then we can feed the C# code through
this C# to JVM compiler and hey presto, everything works.

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

Actually it's trivial to do for the C language, not the C backend --
you can use C typedefs no matter which back-end you are using.
For example, this approach would work fine when compiling C to .NET CLR.

> but
> what about strongly typed backends which don't support typedef like
> behaviour (hmmm can anyone think of one :) ).

Well, .NET CLR and JVM come to mind ;-)

But again I think the question is more about languages that don't
support typedef rather than about backends that don't support typedef.

For example, this issue might arise when using the C back-end
but interfacing with Java (which would presumably be implemented
using JNI). 

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

I think at worst you might have to create proxy objects at the foreign
interface boundary.

For example, if using the C back-end to interface with Java,
then Mercury objects will be represented the same way they
are normally with the C back-end, and so we can't treat
these Mercury objects as if they are Java objects.
However, we can handle this situation by creating
Java objects (on the Java heap) that just contain pointers
to the Mercury objects (on the Mercury heap).
These Java objects can have the names expected by
Mercury's Java language interface.

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

We don't need to solve it right away.
All we need to do now is to get the design right.

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

Nope, that is not needed.  You can do that in Mercury code,
and use `pragma export'.

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

Yes, that sounds good.  This would be essentially just automating
what can be done today manually using Mercury code and `pragma export'.

We've discussed this before, and the concensus has always been that
it would be a good idea.  It's just that as yet there have been
no volunteers to implement it ;-)

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

Well, the stuff about backends in the Mercury language reference manual
is really not acceptable IMHO, even with an XXX.
Supporting all N*M combinations of back-ends and languages would certainly
be a lot of work.  But if you're going to document it at all, then I don't
think documenting what should be implemented in a back-end independent way
is too big an ask.  AFAIK all you really need to do is to change
"<foo> back-end" to "<foo> language" in the appropriate places.

I notice that you've committed some of these changes already...
could you please either fix them to avoid the problematic references
to "backends", or back out these changes?

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

Certainly.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------