[mercury-users] Pred defns

[Fergus Henderson]

On 03-Apr-1998, Peter Schachte <pets at students.cs.mu.oz.au> wrote:
> 
> On Fri, 3 Apr 1998, Fergus Henderson wrote:
> 
> > `:=' would certainly be a good idea, especially given the issue with
> > left-to-right ordering and `##'.  And `:=' would be enough for this
> > particular case.  But '##' or some equivalent would still be needed
> > in other cases, e.g.
> > 
> > 	map__set(#map, Key1, Value1, ##map),
> > 	map__set(#map, Key2, Value2, ##map)
> 
> It's not actually necessary, since you can always write
> 
> 	map__set($map, Key1, Value1, M1), $map := M1,
> 	map__set(#map, Key2, Value2, M2), $map := M2

Well yes, but then the user still has to invent variable numbers
(M1, M2, ...).

> or
> 	set(Key, Value, $$map) :-
> 		map__set($map, Key1, Value1, M1),
> 		$map := M1.
> 
> 	set_map(Key1, Value1, $$map),
> 	set_map(Key2, Value2, $$map)
...

That's OK, but the fact that you have to write an (otherwise unnecessary)
wrapper means that it's not nearly as concise.

So neither of these solutions is ideal.

> > What does your global variables package do for situations like that?
> 
> Actually, I did put in support for this.  It's even more desirable for
> Prolog, since Prolog doesn't even have functions.  The syntax I chose, and
> still don't like, is
> 
> 	map__set($map, Key1, Value1, $:=map),

Hey, it looks OK to me, I'm not sure why you don't like it ;-)

> > Well, the first one is just a unification; but an assignment would work
> > equally well there.
> 
> I know.  I'm arguing that it's preferable because it's more consistent.  If
> you allow inter-predicate threading, it becomes essential since unification
> would be testing the incoming value.

> Let me press you on ### (or $$ or whatever).  Would you allow a ### term to
> stand for a pair of arguments anywhere, or only in calls to predicates that
> are declared to take a thread in that position?

Anywhere.

> I strongly prefer the
> latter because I really don't like the idea of the same predicate appearing
> to have different arities in different places.

Would it help if the "###" operator was "$,$"? ;-)

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.
e.g.
	update($foo, $, $bar, $),	% you can insert spaces after all
	update($foo, $, $bar, $),	% the commas, if you prefer
	...

would expand to

	update(Foo0, Foo1, Bar0, Bar1),
	update(Foo1, Foo2, Bar1, Bar2),
	...

> But if you do adopt the
> latter, how do you specify both the input and output value in a call, and
> get the right mode?  This doesn't come up in Prolog, of course.  Eg,
> 
> 	$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).

Well, that would invoke the (in, out, out) mode, if there is one;
of course, if there is only an (in, in, out) mode, then mode reordering
will ensure that the unification with [] is reorder before the call.

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

If you wish to give the empty list a name, then you could write it as

	$stream := [...],
	$stream_end := [],
	parse($stream, $stream_end, Value).

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

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.