Re: Y, again (long)

[leto!matthias@rice.edu (Matthias Felleisen)]

In article <5684@polya.Stanford.EDU> mxh@sumex-aim.Stanford.EDU (Max Hailperin) writes:
>2) I wasn't weighing the possibility of a compiler defining letrec in
>   terms of Y, I was weighing the possibility of the language standard
>   defining letrec in terms of Y.  While users of Rozas's compiler
>   would notice no difference if he were to do so, users of other less
>   optimizing compilers would notice a difference, namely in
>   "self"-eqvness.  The issue isn't excess eqvnes, either, as Rozas
>   seems to think, but rather insufficient eqvness.  As long as scheme
>   supports procedural objects with identities, letrec will have to
>   remain defined in terms of set! rather than Y.

It is not the R^nRS-specification of eqv? [pp13-14] that requires 
	(letrec ([f (lambda (x) (eqv? f f))]) (f 0)) 
to yield #t but the expansion-specification of letrec [p35]. If we
changed the letrec-specification, the compiler could return any
arbitrary value [recall: eqv? is an approximation of operational
equivalence].

But efficiency is not really the important issue. The assignability of
function variables, in particular for recursive functions, requires
the current letrec-specification. The importance of this cannot be
overemphasized. Dan Friedman and I have shown how to use this trick
for define-by-need and import-by-need in a module environment, and Dan
and John Franco have recently written up a tech rpt on stream
techniques that use this trick.

-- Matthias