[mercury-users] Pred defns

[Peter Schachte]

On Fri, 3 Apr 1998, Fergus Henderson wrote:

> > 	map__set($map, Key1, Value1, $:=map),
> 
> Hey, it looks OK to me, I'm not sure why you don't like it ;-)

Because the := is in the wrong place.  But I can live with it.

> Actually, it would make more sense to write "..., $foo,$, ..."
> rather than "..., $,$foo, ...".
> So how about if a single unadorned "$" in an argument list refered
> to the next state of the accumulator in the previous argument.

That's pretty good.  At least there are enough commas.  And if you've got
$:= as well, you can always use that when the input and output aren't
adjacent.

> > 	$stream = [....],
> > 	parse($$stream, Value),
> > 	$stream = [].		% make sure the whole input is consumed
> >
> > You'd like this to invoke the parse((in,in), out) mode of parse/(2 or 3).

> If there were both (in, in, out) and (in, out, out) modes, and you 
> wanted to invoke the (in, in, out) mode, then you'd just write it as
> 
> 	$stream := [...],
> 	parse($stream, [], Value).

Sure, that'd work, but it's a bit unfortunate mixing the two forms like
that.

If you do write what I wrote above, and Mercury chooses the (in, out, out)
mode, it is, in effect, choosing and implied mode when an exact mode also
applies.  Why would you ever want this?

> > This can be achieved by using an eager unification scheduling algorithm for
> > threads:  as threads are being turned into distinct variables, move
> > unifications with thread variables to the front of the clause.  Your
> > scheduler will push them to the right place.  (I think there's a fair
> > argument for pushing all unifications back to the first place one of the
> > arguments is ground, since this may improve the choice of some modes, but
> > you've probably got a counterargument).
> 
> I think pushing unifications back like this might cause
> some problems for unique modes -- I'm not sure.

Once definite aliasing tracking is in place, I don't imagine this would be a
problem.  And it'd be nice if, at least at more aggressive optimization
levels, Mercury would reorder code in order to use the best modes.  But
then, I'd like to see it generate separate code for implied modes when they
would allow significantly earlier failure (if the implied mode is used).  

I don't ask for much, do I ;-). 


-Peter Schachte               | IBM is not a necessary evil. IBM is not
mailto:pets at cs.mu.OZ.AU       | necessary.
http://www.cs.mu.oz.au/~pets/ |     -- Ted Nelson 
PGP key available on request  |