[m-rev.] for review: implement pragma foreign_export

[Julien Fischer]

On Wed, 12 Jul 2006, Julien Fischer wrote:

>
> Estimated hours taken: 12
> Branches: main
>
> Implement `:- pragma foreign_export'.  This is intended to be a replacement
> for `:- pragma export'.  The principle difference is that `:- pragma
> foreign_export' allows you to restrict exports to a particular foreign
> language.  This language will usually be the target language but in the case
> of backends that support multiple foreign languages, e.g. the IL backend, it
> also allows us to restrict the exports to a subset of the available foreign
> languages.

[I've been discussing this in person with Peter Ross]

Apparently for the .NET backend we cannot restrict exports to a specific
language.  Any export to any of the support foreign languages for that backend
will effectively be an export to all of them.

As I see the main issue with foreign_export is that if I export a particular
Mercury procedure under a specified name to a specified language the I _must_
be able to invoke that procedure from code written in the specified language
(be it in a foreign_proc etc.), by the specified name.  The fact that
procedure might also be implicitly exported to other languages is incidental.

Considering the .NET backend as it currently stands there are currently three
foreign languages that we might export to, IL, Managed C++ and C#.

There are two situations to consider here:

(1) A Mercury procedure is exported to multiple .NET languages under
     different names, e.g.

 	:- pragma foreign_export("IL", foo(in) = out, "ilfoo").
 	:- pragma foreign_export("C#", foo(in) = out, "csharp_foo").

In this case we should just export the procedure under both names.

(2) A Mercury procedure is exported to multiple .NET languages under
     the same name, e.g.

 	:- pragma foreign_export("IL", foo(in) = out, "foreign_foo").
 	:- pragma foreign_export("C#", foo(in) = out, "foreign_foo").

In this case we should just implicitly collapse the duplicate exports into a
single export.  Note, if the two foreign_exports declarations were in
different modules the implicit collapse would not happen but that shouldn't be
a problem as the exported procedures will be in separate namespaces.

I don't think any of this calls for alterations to my diff as "officially" we
do not currently support exports at all for the .NET backend, although one
other change I will make is that we should mention that we support exporting
imported procedures.

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at csse.unimelb.edu.au
administrative address: owner-mercury-reviews at csse.unimelb.edu.au
unsubscribe: Address: mercury-reviews-request at csse.unimelb.edu.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at csse.unimelb.edu.au Message: subscribe
--------------------------------------------------------------------------