bug in scoping for higher order terms

[Fergus Henderson]

On 04-Mar-1999, Juergen Stuber <juergen at mpi-sb.mpg.de> wrote:
> while playing with a Scheme-like promise/delay/force mechanism,
> I had the problem that the two X in the definition 
> 
> delay( X ) = promise( (func) = X ).
> 
> of delay/1 were considered to be distinct variables by the compiler:

This is actually a somewhat subtle issue.  It's not clear exactly when
variables in a pred or func lambda expression should be considered
fresh variables.  The language reference manual doesn't say anything
about that (which is certainly a bug), and I'm not sure from a language
design point of view what the best approach is.

Consider the following example:

	p(A, B, C, P) :-
		q(A, B, C),
		P = (pred(A::in, B::in, C::out) is semidet :- A+B=C).

Should the variables A, B, C in the last line be distinct from
the ones in the first two lines?

If so, what about this example:

	p(A, B, C, P) :-
		q(A, B, C),
		P = (func(A::in, B::out) = (C::in) is semidet :- A+B=C).

Should the variables A, B, C in the last line be distinct from
the ones in the first two lines?

In functional languages, there is a big distinction between the
a function's return value and its arguments.  This distinction
becomes blurred in a logic language.

Perhaps we should just say that variables in a lambda expression
are *never* distinct from variables occurring outside; that would
mean that if you want a fresh variable, then you must use a
different variable name.  On the other hand, that might surprise
functional programmers almost as much as the above case does.

Comments?  Opinions?

> As a workaround I applied an identity-function id/1 to X.

Another work-around that is perhaps a little simpler is to write it as

	delay( X ) = promise( (func) = Y :- Y = X ).

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