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

[Ralph Becket]

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

> +
> + at example
> +:- pragma foreign_enum(@var{Lang}, @var{MercuryTypeName}, 
> @var{NameMapping}).
> + at end example

I suggest foreign_export_enum rather than just foreign_enum.

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

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

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

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