[m-dev.] completing the new foreign language interface

[Jonathan Morgan]

On 7/7/06, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
> Currently the reasons given in the reference manual for not deprecating the
> old C interface are that the new foreign language interface has no equivalent
> for `pragma import' and `pragma export'.  (It also says that the new one isn't
> as well tested as the old one but for the most part that's not really valid
> anymore.)
>
> In order to "complete" the new foreign language interface (at least to a point
> where we can start to get rid of the old one), I am proposing the following:
>
> (1) that the new interface does not need an equivalent for `pragma import'.

I have never used it, but it could provide a useful shorthand.

> (2) that we introduce `pragma foreign_export' declarations to the new
>     interface.  These carry out the function of `pragma export' in the old
>     interface but are intended to work with backends other than the C
>     backends.

I have used pragma export with the IL backend (both C# and IL).  It
seemed to work OK.

>
> (2)  Unlike (1) we definitely need this.  I'm proposing that in introducing
>      `pragma foreign_export' we make a fairly minimal change and just require
>      that a language be specified in addition to the other information that
>      is already in export pragmas.
>
>      foreign_export pragmas would work in a similar fashion to the other
>      `foreign_*' pragmas. i.e they would only be considered by the compiler
>      when compiling to a compatible backend, so that
>      `:- pragma foreign_export("C", ...)' would only apply for the C backends,
>      `:- pragma foreign_export("Java", ...) for the Java backend etc.
>
>      For the .NET backend, where we support several possible foreign languages,
>      we would use the same technique that we do with foreign_procs.
>      C# and MC++ exports would be hoisted into separate C# and MC++ files
>      and compiled separately.

Currently pragma export under the .NET backend make the exported
function part of the generated IL code, wrapped in the mercury_code
class.  This shouldn't cause any problems for users, and can be
accessed from C# and MC++ code.  In what situations would it be
necessary to export different functionality to different backends?
Does it really matter if functionality is just exported to all
backends?  It is obviously necessary to have different implementations
for the different backends - I don't think that it is so necessary to
have different exports for the different backends, and it could be
much more cumbersome.

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