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

[Julien Fischer]

On Tue, 26 Sep 2006, Jonathan Morgan wrote:

> On 26/09/06, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>> 
>> On Mon, 25 Sep 2006, Julien Fischer wrote:
>> >> 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?
>
> This would be a nice feature.  However, backends based on MLDS that
> use the high-level representation may not map easily to enumerations
> (for example, in IL it maps to the inner class
> <module>.mercury_code.<type name>.<constructor name>, of type
> <module>.mercury_code.<type name>).  I suspect that you would be
> better providing a set of constants in some way, at least for some
> backends.  These would also have the advantage (I presume) that these
> constants only have to be constructed once (though they must be
> immutable, otherwise interesting results may follow).

This feature won't be available on all backends.  At the moment
it will be straightforward enought for the C and Java backends.  I
hadn't given much thought to the IL backend.  In any case the feature
does not necessarily have to map Mercury enums on to target enums.  It
might for example map Mercury enums on to a set of constant functions
in the target language that return the appropriate value.  (The exact
details will obviously be dependent on, and vary with, the target
language.)

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