[m-rev.] for review: pragma foreign_export_enum

[Julien Fischer]

On Tue, 24 Jul 2007, Peter Wang wrote:

>>  compiler/mlds_to_c.m:
>>  	Output #defined constants for C foreign_export_enum pragmas in
>>  	.mih files.
>
> Is it not enough to write them to the .mh files?

No, the decl guards in the .mih files prevent those in the .mh files
being included.  (The export enumeration constants are defined within
the the same #ifdef block as any stuff from non-local foreign_decl
pragmas - whose contents are also duplicated in .mih and .mh files.)

I'm not entirely sure why user declarations in C are handled this
way by the high-level C backend; it _seems_ unnecessary.  I intend
to take a look at it separately.  (At a guess it may be like that
because previously the .mh file for a module was not always #included, 
although that has not been the case for a while now.)

>>  +:- pred build_overrides_map(sym_name::in, prog_context::in,
>>  +    format_components::in, assoc_list(sym_name, string)::in,
>>  +    maybe(map(sym_name, string))::out,
>>  +    list(error_spec)::in, list(error_spec)::out) is det.
>
> I suggest renaming that.

Which?  And what do you suggest calling it?

>>  + +:- pred build_export_enum_name_map(format_components::in,
>>  +    foreign_language::in, sym_name::in, arity::in, prog_context::in,
>>  +    string::in, map(sym_name, string)::in, list(constructor)::in,
>>  +    maybe(map(sym_name, string))::out,
>>  +    list(error_spec)::in, list(error_spec)::out) is det.
>>  +

...

>>  Index: compiler/mlds.m
>>  ===================================================================
>>  RCS file: /home/mercury1/repository/mercury/compiler/mlds.m,v
>>  retrieving revision 1.150
>>  diff -u -r1.150 mlds.m
>>  --- compiler/mlds.m	15 Jun 2007 12:12:30 -0000	1.150
>>  +++ compiler/mlds.m	12 Jul 2007 05:25:04 -0000
>
>>  @@ -381,7 +382,8 @@
>>                   % XXX These only work for the C backend because
>>  initialisers
>>                   % and finalisers do not (yet) work for the other backends.
>>                   init_preds          :: list(string),
>>  -                final_preds         :: list(string)
>>  +                final_preds         :: list(string),
>>  +                exported_enums      :: list(mlds_exported_enum)
>
> Mention that these are in reverse order (if they are).

The list of initise and finalise preds are the correct way around at
this point.  For exported enumerations the order is not important - 
although they too are around the "right", i.e the order in which they
occured in the source file, way here too.

...

>>  +The body of each of these macros expands to a value that is identical
>>  +to that of the constructor to which the symbolic name corresponds in
>>  +the mapping established by the @samp{pragma foreign_export_enum}
>>  +declaration.
>>  +
>>  +As noted in the @pxref{C data passing conventions}, the type of these
>>  +values is @samp{MR_Word}.
>>  +
>>  +The default mapping used by @samp{pragma foreign_export_enum}
>>  +declarations for  C is to use the Mercury constructor name as the
>>  +base of the symbolic name.
>
> Add an example here.

Ok.

 	For example, the base of the the symbolic name for the
 	Mercury constructor @samp{foo} would be @code{foo}.

> The rest is probably fine.

Probably?

I've followed the rest of your suggestions.
Thanks for the 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
--------------------------------------------------------------------------