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