[m-rev.] for review: dumping trace counts

[Julien Fischer]

On Wed, 27 Sep 2006, Ralph Becket wrote:

> Julien Fischer, Tuesday, 26 September 2006:
>>
>> Here's a reference manual diff that outlines the mechanism in the
>> simple case.  It's a bit rough and a lot of the details are XXXs at
>> the moment - also I don't like the name foreign_enum, but couldn't
>> think of a better one.  Comments, suggestions?
>>
>> Index: reference_manual.texi
>> ===================================================================
>> RCS file: /home/mercury1/repository/mercury/doc/reference_manual.texi,v
>> retrieving revision 1.369
>> diff -u -r1.369 reference_manual.texi
>> --- reference_manual.texi	26 Sep 2006 07:10:54 -0000	1.369
>> +++ reference_manual.texi	26 Sep 2006 07:39:37 -0000
>> @@ -6101,7 +6101,9 @@
>>                                         programming language.
>>  * Using foreign types from Mercury::   How to use a type defined in
>>  				       a different programming language
>> -				       in Mercury code.
>> +				       in Mercury code.
>> +* Using Mercury types from foreign code:: How to use a type defined in
>> Mercury
>> +                                          in a different programming
>> language.
>>  * Data passing conventions::	       How Mercury types are passed to
>>  				       different languages.
>>  * Adding foreign declarations::        How to add declarations of
>> @@ -6745,6 +6747,62 @@
>>
>>  @c -----------------------------------------------------------------------
>>
>> + at node Using Mercury types from foreign code
>> + at section Using Mercury types from foreign code
>> +
>> +XXX Stuff about atomic types here ... or pointer to data passing
>> conventions
>> +XXX In general you need to export access predicates ...
>> +
>> +For Mercury enumerations, that is a discriminated union type that consists
>> +of two or more zero arity constructors, it is also possible to create
>> +a symbolic representation for each constructor that may be use to refer
>> +to that constructor in foreign language code.
>
> Grammar error.

... hence me saying it was a bit rough


> How about this:


>  It is possible to refer to values with Mercury enumeration types (i.e.,
>  discriminated unions consisting of two or more arity zero data
>  constructors) in foreign code.
>
>> +XXX This is only possible with target languages that support having some
>> +    sort of named constant.
>> +
>> +The names for each constructor can be declared using a declaration of the
>> +form:
>
> How about:
>
>  A correspondence between the Mercury enumeration names and the
>  corresponding foreign names must be set up as follows:
>
Yes, although s/must/may/

>> +
>> + at example
>> +:- pragma foreign_enum(@var{Lang}, @var{MercuryTypeName},
>> @var{NameMapping}).
>> + at end example
>
> I suggest foreign_export_enum rather than just foreign_enum.

Hmmmmm ... we already have a foreign_export but I guess I could live
with that.

>> +This defines a set of symbolic names in the language @var{Lang} that
>> +correspond to the representation of the constructors of the enumerated
>> +type @var{MercuryTypeName} in Mercury.
>
> I'd delete the paragraph above.  It's unnecessary.
>
>> +The mapping @var{NameMapping} specifies a mapping from the constructors
>> +of @var{MercuryTypeName} to symbolic names in language @var{Lang}.
>
> Instead just add here:
>
>  The symbolic names are visible in foreign code in language @var{Lang}.
>
> XXX I assume the symbolic names have type MR_Word or MR_Integer?

On the C backends maybe, on the others no.  This bit of the reference
manual is a general description of the feature.  Details like that
are obviously language specific.  For the C backends I was thinking of
saying just that the symbolic names have an integral type (which if
they are implmemented as #defines or enums is pretty much all we can
say).

>> It
>> +has the following form:
>> +
>> + at example
>> +[ cons1 - "symbol1", cons2 - "symbol2", ..., consN - "symbolN"]
>> + at end example
>> +
>> +Here each @samp{consN} is one of the constructors of the type
>> + at var{MercuryTypeName} and each @samp{symbolN} is an identifier suitable
>> +for use as symbolic constant in language @var{Lang} (XXX see language
>> +specific bindings for more details).
>
> How about:
>
> Here each @samp{consN} is a constructor of
> @var{MercuryTypeName} and each @samp{symbolN} is a distinct identifier
> suitable for use as symbolic constant in language @var{Lang} (XXX see
> language specific bindings for more details).
>
>> +
>> +The name-mapping need not include all the constructors of
>> +type @var{MercuryTypeName} but it must include at least one of them.
>> +
>> +It is an error for two different constructors to map on to the same
>> symbolic
>> +name.
>> +XXX Is it an error for one constructor to map on to two different symbolic
>> +names?  (Some target languages might get stroppy.)
>
> I don't see why not, although one might argue that such a situation is
> more likely to be a bug than deliberate.

Yep.

>> +XXX Also is it an error to have two separate foreign_enum decls for the
>> +    same Mercury type?  (I would think not).
>> +
>> + at c We might also want to include a list of attributes that specify,
>> + at c for example, whether we map onto a bunch of #defines in C or an enum
>> + at c in C (and in the latter case we might also want to give the enum a name)
>> +
>> + at c -----------------------------------------------------------------------
>> +
>
> We also need foreign_import_enum which would be identical as far as the
> Mercury code was concerned, but which depended upon the foreign language
> side defining the values.  Of course, the values would have to be
> distinct, but I can't see how we could check that statically.

You can't.  Also for the C backends a common use of this feature would
be to give Mercury enums values that correspond to #defined values
in C - this leads to all sorts of nastiness with the build system among
other things.

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