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

[Julien Fischer]

On Mon, 25 Sep 2006, Julien Fischer wrote:

>
> On Mon, 25 Sep 2006, Ralph Becket wrote:
>
>>> +#ifdef  MR_EXEC_TRACE
>>> +    FILE    *fp;
>>> +
>>> +    if (MR_trace_count_enabled && MR_trace_func_enabled) {
>>> +        fp = fopen(FileName, ""w"");
>>> +        if (fp != NULL) {
>>> +            MR_trace_write_label_exec_counts(fp, MR_FALSE);
>>> +            Result = 0;
>>> +            (void) fclose(fp);
>>> +        } else {
>>> +            Result = 3;
>>> +        }
>>> +    } else {
>>> +        Result = 2;
>>> +    }
>>> +#else
>>> +    Result = 1;
>>> +#endif
>>> +").
>>> +
>>> +% Default definition for non-C backends.
>>> +dump_trace_counts_to(_, 1, !IO).
>>> +
>> 
>> The business of magic numbers in mixed C/Mercury code crops up often
>> enough that we really should provide better support for sharing
>> constants between Mercury and foreign code.
>
> There was a discussion on mercury-users (developers?) a while back about
> this sort of thing.  The simple case, mapping a Mercury enumeration
> onto an enumerated constant in the target language (assuming the target
> language has something that can act like an enumerated constant) is
> pretty straightforward.
>

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.
+
+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:
+
+ at example
+:- pragma foreign_enum(@var{Lang}, @var{MercuryTypeName}, @var{NameMapping}).
+ at end example
+
+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.
+
+The mapping @var{NameMapping} specifies a mapping from the constructors
+of @var{MercuryTypeName} to symbolic names in language @var{Lang}.  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).
+
+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.)
+
+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 -----------------------------------------------------------------------
+
  @node Adding foreign declarations
  @section Adding foreign declarations

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