Newsgroups: comp.lang.scheme
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!mintaka.lcs.mit.edu!alan
From: alan@lcs.mit.edu (Alan Bawden)
Subject: Re: eqness of procedures
In-Reply-To: hanche@imf.unit.no's message of 11 May 91 14:40:38 GMT
Message-ID: <ALAN.91May12163401@august.lcs.mit.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: ITS Preservation Society
References: <9105080039.aa09228@mc.lcs.mit.edu>
	<1991May8.063427.25012@Think.COM>
	<ALAN.91May9100139@august.lcs.mit.edu>
	<CARLTON.91May10135234@husc10.harvard.edu>
	<ALAN.91May10232758@august.lcs.mit.edu>
	<HANCHE.91May11164038@hufsa.imf.unit.no>
Date: 12 May 91 16:34:01
Lines: 33

In article <HANCHE.91May11164038@hufsa.imf.unit.no>
hanche@imf.unit.no (Harald Hanche-Olsen) writes:

   In article <ALAN.91May10232758@august.lcs.mit.edu>
   alan@lcs.mit.edu (Alan Bawden) writes:

      I can imagine a programmer thinking it would be convenient if every
      evaluation of a LAMBDA-expression resulted in a unique (in the sense
      of EQ?) closure.

   If I have understood it right, that form is required to be false because
   of the existence of procedures like set-car! and set-cdr!  which could
   change equal-looking objects to look different.  You cannot change a
   closure in an analogous way.  So what is so convenient about (lambda (x)
   x) not being eq? to (lambda (x) x) ?

Well, I confess I'm not certain where this desire comes from really.  Note
please that nothing I have said so far indicates that I myself subscribe to
this desire -- when pressed to the wall I will generally agree that the
behavior should be unspecified -- but I know that I have wished otherwise
upon occasion, and I have seen others want it as well.  It usually seems to
happen when using closures for a certain style of object oriented
programming.

If anyone wants a real example where Scheme programmers wanted more
constraints on the EQ-ness of procedures than the standard guarantees, they
should look in the 1988 L&FP proceedings for a paper by Rees and Adams.
Fairly early on in the paper the authors remark that a sufficiently smart
compiler can foil their intentions by recognizing that a certain closure
need only be created once -- but they trust that any competent programmer
can sufficiently confuse his compiler so as to prevent the problem.  [I
think this reference is right, I can't seem to lay my hands on a copy of
the LFP88 proceedings right now.]
