[m-rev.] for review: pragma foreign_export_enum

[Julien Fischer]

> On 2007-07-25, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>
>>  On Tue, 24 Jul 2007, Peter Wang wrote:
>
>>>>  +:- 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?
>
> build_export_enum_overrides_map?

Ok.

>>>>  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.
>>
>
> Ok, I thought that I saw a list.reverse on the exported enums somewhere.

Yes, that's on the list of constructor - name mappings within each
export enum declaration.  (Strictly speaking it's also unnecessary
but it's nicer if they appear in order.)

>>
>>>>  +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}.
>
> It wasn't clear to me where the "base" fits in.  It comes after the
> prefix, and there's no other components in the name.

Deleted the base bit.  (The idea here was to try and specify more
carefully what happens in the presence of other attribues - of
which there aren't any (yet)).

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