[m-rev.] for review: dumping trace counts
Jonathan Morgan
jonmmorgan at gmail.com
Tue Sep 26 19:10:25 AEST 2006
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).
Jon
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------
More information about the reviews
mailing list