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

[Julien Fischer]

On Sat, 15 Jul 2006, Jonathan Morgan wrote:

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

It would be possible to add an attribute to the foreign_export pragmas that
did this - although I see no call for it now.

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

... for supported foreign languages.  Yes.

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

I don't know.  We haven't really used it since the C# interface was added
so arguably there isn't a lot of point in supporting it now.

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

Ah, I was mistaken about what was happening there, I thought that all of the
exports were being placed in the same namespace regardless of language - if
they're being placed in different namespaces then there isn't a problem with
just exporting all of them separately.

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