[m-rev.] for review: MR_DEFINE_ENUM_CONST

[Mark Brown]

On 30-May-2001, David Jeffery <dgj at cs.mu.OZ.AU> wrote:
> Hi,
> 
> For Fergus, Tyson or Mark to review.
> 

The diff looks fine to me.


> This has bootchecked in asm_fast.gc.rt, and the bootcheck in asm_fast.gc is
> still running.
> 
> Let me know if you think any other specific grades need checking. I can't
> think of any.
> 
> ---------------------------------------------------------------------------
> 
> Estimated hours taken: 20
> 
> Branches: main
> 
> This diff fixes a bug that was causing the test case 
> tests/debugger/browser_test to fail in .rt grades. The problem was that some
> code in the browser/tracer was assuming that the representation of Mercury
> bools was '0'/'1'. This is not the case if we reserve the '0' tag for
> variables.
> 
> runtime/mercury_tags.h:
> 	Define a macro 'MR_DEFINE_ENUM_CONST' for wrapping around the
> 	declarations of enumeration constants in C. The macro causes the
> 	enumeration constant to be assigned the same value as our tag
> 	allocation scheme assigns its Mercury counterpart. (In most grades
> 	this is a no-op... in .rt grades it has to take the reserved tag
> 	into account).
> 
> runtime/mercury_stack_layout.h:
> runtime/mercury_type_info.h:
> trace/mercury_trace_browse.h:
> 	Wrap enum definitions in 'MR_DEFINE_ENUM_CONST'.
> 
> XXX:
> 	- I have wrapped all the 'enum' declarations that I could find that
> 	seemed to correspond to Mercury types. I have left all the others
> 	alone. Perhaps there are some that I've missed? I don't think so.
> 	In any case, we need to make sure that any code checked in in the 
> 	future wraps enum declarations in the new macro.
> 	- dougl's bug fix that he committed yesterday fixed some of the places
> 	(in the tracer) that assume that 'no' and 'yes' are assigned '0' and 
> 	'1' (whereas they are probably assigned '1' and '5' in .rt grades).
> 	He did so by exporting a function from Mercury and using that in C.
> 	Perhaps now we should define a C enum (with the wrapper macro) and use
> 	*that* to test Mercury enums against when in C code instead.
> 

That would be more efficient, since we wouldn't need to cross the
C->Mercury boundary.  However, since this is only done once each time
the 'set' command is given in mdb, I don't think efficiency is a major
issue.

On the other hand, using functions exported from Mercury is more portable
than defining an enum for bool__bool, since it relies only on what is
documented in the reference manual.  If the method of defining a C enum
for a Mercury enumeration was actually part of the language then I would
do it that way, but for now I'd rather leave it as it is.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------