[m-dev.] for review: RL bugs

[Simon Taylor]

> On 15-Jun-1999, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > 
> > compiler/rl_exprn.m:
> > 	Fix a bug which caused missing constant declarations in the
> > 	RL generated for aggregate goals.
> > 
> > 	Remove some code duplication for generation of constant
> > 	and constructor declarations.
> > 
> > 	For consistency, return the list of variable types for
> > 	key range expressions, even though it should currently
> > 	always be empty.
> > 	
> > compiler/rl_out.pp:
> > 	Handle the variable types returned for key range expressions.
> > 
> > compiler/tree.m:
> > 	Added `tree__tree_of_lists_is_empty', which is similar to
> > 	`tree__is_empty' except that `node([])' is also considered empty.
> > 	This is useful for trees of instructions.
> > 
> > compiler/lookup_switch.m:
> > compiler/rl_gen.m:
> > 	Use `tree__tree_of_lists_is_empty' instead of `tree__is_empty'.
> 
> Those changes look fine.  But the log message is missing an overall
> description of what these changes accomplish.
> 
> I think the first group (the first two changes) and the second group
> (the remaining changes) are unrelated and should therefore be committed
> separately.  The log message should explain the rationale for the
> second group.
 

Estimated hours taken: 0.5

Most of the uses of the type `tree:tree/1' are lists of instructions.
`tree__is_empty' is used to ask "was any code generated", but 
`tree__is_empty' fails for `node([])'. This has not been a problem
in the past because the code generator builds up a trees of lists that
are known to be non-empty. Parts of the RL generation code can create
empty lists of instructions, and it can't hurt to test for this
case elsewhere.

compiler/tree.m:
	Added `tree__tree_of_lists_is_empty', which is similar to
	`tree__is_empty' except that `node([])' is also considered empty.

compiler/lookup_switch.m:
compiler/rl_gen.m:
	Use `tree__tree_of_lists_is_empty' instead of `tree__is_empty'.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------