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

[Julien Fischer]

On Wed, 19 Jul 2006, Ian MacLarty wrote:

>> compiler/hlds_module.m:
>> 	Add an extra field the pragma_exported_proc structure to hold the
>
> Add an extra field *to* the prag...
>

Fixed.

>> 	name
>> 	of the foreign language that the corresponding foreign_export
>> 	declaration is for.
>>
>> compiler/mercury_to_mercury.m:
>> 	Add code to output foreign_export pragmas.
>>
>> compiler/ml_code_gen.m:
>> 	Don't filter out exports for Java, C# and MC++.  The Java exports
>> 	can now be passed down to mlds_to_java.m and other two ought to
>
> ...and *the* other two...

Fixed.

>> doc/reference_manual.texi:
>> 	Add a new section to the foreign language interface chapter
>> 	documenting the new pragma.
>>
>> 	Update the descriptions of the language specific bindings to include
>> 	the new pragma.
>>
>> tests/hard_coded/Mmakefile:
>> tests/hard_coded/pragma_foreign_export.{m,exp}:
>> 	Make sure that we can parse the new syntax and run a simple program
>> 	that uses exported procedures.
>>
>
> Are you planning to replace all uses of ":- pragma export" in the
> compiler (such as in browser/declarative_debugger.m) with the new pragma
> in a subsequent diff?
>

Not immediately.

>> Index: compiler/modules.m
>> ===================================================================
>> RCS file: /home/mercury1/repository/mercury/compiler/modules.m,v
>> retrieving revision 1.395
>> diff -u -r1.395 modules.m
>> --- compiler/modules.m	28 Jun 2006 04:46:16 -0000	1.395
>> +++ compiler/modules.m	10 Jul 2006 07:05:56 -0000
>> @@ -2111,7 +2111,7 @@
>>  pragma_allowed_in_interface(inline(_, _), no).
>>  pragma_allowed_in_interface(no_inline(_, _), no).
>>  pragma_allowed_in_interface(obsolete(_, _), yes).
>> -pragma_allowed_in_interface(export(_, _, _, _), no).
>> +pragma_allowed_in_interface(foreign_export(_, _, _, _, _), no).
>>  pragma_allowed_in_interface(import(_, _, _, _, _), no).
>>  pragma_allowed_in_interface(source_file(_), yes).
>>      % yes, but the parser will strip out `source_file' pragmas anyway...
>> @@ -5857,11 +5857,11 @@
>>          % code for it, rather than assembler code.  So
>>          % we need to treat `pragma export' like the
>>          % other pragmas for foreign code.
>> -        Pragma = export(_, _, _, _),
>> -        list.member(lang_c, BackendLangs)
>> +        % XXX How is this going to be affected now we have moved
>> +        % to pragma foreign_export? - juliensf
>
> I don't understand this comment.  Could you elaborate?

At the time I wrote that I wasn't sure how mlds_to_gcc.m would 
handle exports for other languages.  As it turns out, at least
according to the comments in that module, it isn't implemented.
I've deleted the XXX comment as it should no longer be needed.

>> Index: doc/reference_manual.texi
>> ===================================================================
>> RCS file: /home/mercury1/repository/mercury/doc/reference_manual.texi,v
>> retrieving revision 1.357
>> diff -u -r1.357 reference_manual.texi
>> --- doc/reference_manual.texi	5 Jul 2006 08:45:37 -0000	1.357
>> +++ doc/reference_manual.texi	12 Jul 2006 08:05:27 -0000
>> @@ -6071,6 +6071,9 @@
>>  				       or function as a call to code
>>  				       written in a different
>>  				       programming language.
>> +* Calling Mercury from foreign code::  How to call a Mercury predicate
>> +                                       or funciton from a different
>> +                                       programming language.
>>  * Using foreign types from Mercury::   How to use a type defined in
>>  				       a different programming language
>>  				       in Mercury code.
>> @@ -6388,6 +6391,41 @@
>>
>>  @c -----------------------------------------------------------------------
>>
>> + at node Calling Mercury from foreign code
>> + at section Calling Mercury from foreign code
>> +
>> +Mercury procedures may be exported so that they can be called by code
>> written
>> +in a foreign language.
>> +
>
> I think you need to clarify that the foreign code that calls the Mercury
> code must in turn have been called from Mercury code, or alternatively
> the user needs to take steps to initialize the Mercury runtime before
> calling the exported procedure.

Yes, but I'm not going to do that as a part of this diff.  Currently
the only documentation we can point a user to for doing that is the 
code in samples.  I'm planning to write a new section for the user's
guide on initialising the runtime as part of the standalone libraries
change - I'll update this section then.

>> Index: tests/invalid/invalid_export_detism.err_exp
>> ===================================================================
>> RCS file:
>> /home/mercury1/repository/tests/invalid/invalid_export_detism.err_exp,v
>> retrieving revision 1.2
>> diff -u -r1.2 invalid_export_detism.err_exp
>> --- tests/invalid/invalid_export_detism.err_exp	14 Sep 2005 05:26:47
>> -0000	1.2
>> +++ tests/invalid/invalid_export_detism.err_exp	11 Jul 2006 12:26:35
>> -0000
>> @@ -1,3 +1,3 @@
>> -invalid_export_detism.m:009: Error: `:- pragma export' declaration for a
>> -invalid_export_detism.m:009:   procedure that has a declared determinism of
>> +invalid_export_detism.m:009: Error: `:- pragma foreign_export' declaration
>> for
>> +invalid_export_detism.m:009:   a procedure that has a declared determinism
>> of
>>  invalid_export_detism.m:009:   nondet.
>
> You might want to also test the warnings for non-c pragma
> foreign_exports.

Ok.  (although I'll add that 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
--------------------------------------------------------------------------