Re^2: Scheme Digest #8, Efficiency of Y

[zodiac!DUCHAMPS.ADS.COM!rar@ames.arpa (Bob Riemenschneider)]

Max Hailpern writes:

=>   There is another reason, in Scheme, not to use Y: it breaks the fact
=>   that you can use procedures as objects.  While the R^3R says that a
=>   procedure created by a given lambda at a given time will be eqv to
=>   itself (and implies eq as well, though on looking I see that isn't in
=>   there -- is this a mistake?), the same does not necessarily hold for
=>   the various incarnations of a procedure that Y will churn out (or
=>   rather, that Y is entitled to churn out: presumably in Rozas's
=>   implementation there is indeed only one procedure).
=>
=>   Perhaps I'm wrong to mix together such disparate worlds as Y and
=>   eqvness of procedures belong to, but I do consider this to be
=>   something of an issue.  Does anyone else?

Could you provide a specific example?  I don't see how Y makes the situation 
any worse than lambda.  Just as you might decide to write

		   (let ((p (lambda (n) ...n...)))
		       ===p===p===)

rather than 

		===(lambda(n) ...n...)===(lambda (n) ...n...)===

because Scheme doesn't guarantee that even syntactically identical lambda
terms will test equivalent---Does anyone know why 'operational equivalence'
for procedures was defined extensionally, making it uncomputable, rather
than intensionally (say, in terms of alpha-convertability)?--, you might
decide to write

		    (let ((p (Y (lambda (q) ...q...))))
			===p===p===)

rather than 

	  ===(Y (lambda(q) ...q...))===(Y (lambda (q) ...q...))===

Arguments against Y that apply equally well to lambda don't count! 

							-- rar