Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!husc6!rice!leto!matthias
From: matthias@leto.rice.edu (Matthias Felleisen)
Newsgroups: comp.lang.scheme
Subject: Re: Y, again (long)
Message-ID: <2356@kalliope.rice.edu>
Date: 16 Dec 88 18:27:47 GMT
References: <8812151447.AA06672@chamartin.ai.mit.edu> <5684@polya.Stanford.EDU>
Sender: usenet@rice.edu
Reply-To: matthias@leto.rice.edu (Matthias Felleisen)
Organization: Rice University, Houston
Lines: 27

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