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

[Jonathan Morgan]

On 7/14/06, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>
> 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.

Could you not export them as private or protected functions, rather
than public functions?  While this is not desirable, it would enable
you to block their use from other languages.

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

So therefore you must honour all exports.

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

How long will we continue supporting Managed C++ if Microsoft dumps it
in favour of C++/CLI?

>
> 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'm inclined to disagree.  As you state, the exported procedures are
held in different namespaces.  This means that foreign exports should
always be made to the physical file and namespace that they are
requested to be exported to.  For example, an export to C# would
appear in <module>__csharp_code.mercury_code.foreign_foo, which is
just foreign_foo to C# foreign_procs, while the export to IL is
<module>.mercury_code.foreign_foo to C#, and foreign_foo to IL
foreign_procs.  If you only place the export in the one place then you
are left with it being implementation defined which of the three it is
in fact exported to.  It could lead to the situation that code that
works breaks, just because another foreign_export is added, and the
foreign export the existing foreign_code relies on has just
disappeared.

I see that making each foreign_export separate to the module the
foreign procedures and code are in mean that the user has less need to
know about how exactly the implementation handles it.  C# foreign code
users can work solely in C#, and IL users can work solely with IL.

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