[m-rev.] for review: pragma foreign_export_enum

[Peter Wang]

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?

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

Ok, I thought that I saw a list.reverse on the exported enums somewhere.

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

> > The rest is probably fine.
> 
>  Probably?

Surely fine :-)

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