[m-rev.] for review (needs committing): Document and fix pragma foreign_export("IL")

Julien Fischer juliensf at csse.unimelb.edu.au
Wed Jan 3 13:20:37 AEDT 2007


> On 1/2/07, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:

>> > Make the
>> > MLDS filter foreign exports by foreign language (this is not a problem
>> 
>> I suggest:
>> 
>>         Make the MLDS backend filter out those foreign_export pragmas
>>         that are not supported by the current compilation target.
>
> That's not what it is doing.  The definition for foreign code in the
> MLDS is as follows:
>
>               % Code defined in some other language, e.g.  for
>               % `pragma c_header_code', etc.
>               foreign_code_map    :: map(foreign_language,
>                                       mlds_foreign_code)
>
> Previously what happened was that the entry for lang_il got all the
> exports for IL, C# and MC++, and so did the entries for lang_csharp
> and lang_mcpp.  This change filters it so that the entry for lang_il
> only gets the exports for lang_il, the entry for lang_csharp only gets
> the exports for lang_csharp, etc.  This was not a problem for C or
> Java, as there was only one foreign language and one entry in the map,
> so there was nothing to filter on.  However, it was a problem for IL,
> because it produced one export for IL, one export for C#, and one
> export for MC++ (the way it did this was buggy, but I will address
> that when I implement foreign_export for C#).

I suspect the old behaviour was deliberate, i.e it was a way of 
ensuring that all of the supported languages got passed to the
appropriate backend.  That said, I have no objections to changing
it.

...

>> > Index: doc/reference_manual.texi
>> > ===================================================================
>> > RCS file: /home/mercury1/repository/mercury/doc/reference_manual.texi,v
>> > retrieving revision 1.373
>> > diff -u -r1.373 reference_manual.texi
>> > --- doc/reference_manual.texi 4 Dec 2006 04:30:50 -0000       1.373
>> > +++ doc/reference_manual.texi 29 Dec 2006 10:58:35 -0000
>> > @@ -7399,7 +7399,54 @@
>> > @node Using pragma foreign_export for IL
>> > @subsubsection Using pragma foreign_export for IL
>> >
>> > - at samp{pragma foreign_export} is currently not supported for IL.
>> > +A @samp{pragma foreign_export} declaration for IL has the form:
>> > +
>> > + at example
>> > +:- pragma foreign_export("IL", @var{MercuryMode}, "@var{IL_Name}").
>> > + at end example
>> > +
>> > +For example,
>> > +
>> > + at example
>> > +:- pragma foreign_export("IL", foo(in, in, out), "foo").
>> > + at end example
>> > +
>> > +For each Mercury module containing @samp{pragma foreign_export} 
>> declarations
>> > +for IL, the Mercury implementation will automatically create a static 
>> method
>> > + at var{IL_Name}() in the <module_name>.mercury_code class for each of the
>> > + at samp{pragma foreign_export} declarations.
>> 
>> > + Each such IL method is the
>> > +.NET interface to the specified Mercury procedure, and should be usable 
>> from
>> 
>> s/the .NET interface/a .NET interface/ since presumably any C# or MC++
>> exports for the same procedure would also consistitute a .NET interface to
>> it.
>
> I'll agree with the change, but I still think that the IL export will
> constitute the main .NET interface, whereas I see the exports to other
> languages as conveniences for those implementing the interface in
> foreign code in that language.  It certainly seems to me more sensible
> to use <module>.mercury_code.method() from a different module, rather
> than <module>__csharp_code.mercury_code.method() or
> <module>__cpp_code.mercury_code.method().

It's difficult to say whether that will be the case until it actually works
and people start using it.

That's fine otherwise - could you please repost the log message + diff
after you address any review comments.

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list