Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!dircon!rheged!simon
From: simon@rheged.dircon.co.uk (Simon Brooke)
Subject: SETF (was Re: Why do people like C? (Was: Comparison: Beta - Lisp))
Message-ID: <Cy3E67.42K@rheged.dircon.co.uk>
Organization: none. Disorganization: total.
References: <Pine.A32.3.91.941014091539.42306C-100000@swim5.eng.sematech.org> <hbakerCxquDG.LEF@netcom.com> <Cxxwx0.1nC@rheged.dircon.co.uk> <hbakerCy17CC.vx@netcom.com>
Date: Sat, 22 Oct 1994 20:56:30 GMT
Lines: 66

In article <hbakerCy17CC.vx@netcom.com>,
Henry G. Baker <hbaker@netcom.com> wrote:
>In article <Cxxwx0.1nC@rheged.dircon.co.uk> simon@rheged.dircon.co.uk (Simon Brooke) writes:
>
>>(iia6) I have complained often enough before about the abhomination,
>>SETF. I rehearse my objections briefly. Destructively altering lists
>>may be dangerous, and should always be done consciously and with care.
>>If you use RPLAC, you know you what you are doing. SETF makes
>>destructive change invisible to the naiive user: it says 'take this bit
>>of memory, I don't know where it is, I don't know who owns it, I don't
>>know who else is holding pointers to it, and trample all over it'.
>>It's direct equivalent is the BASIC keyword, POKE. I *shudder*.
>
>I agree that SETF is a real kludge, because it is trying to make up
>for the lack of 1st class 'references'.  The Lisp machine provided for
>invisible pointers, but they don't take care of the case of 1 bit
>within a word.  A run-time implementation would have to cons a 'dope
>vector' or equivalent to achieve the same effect.
>
>Today, if someone wanted a truly _clean_ implementation of SETF-like
>constructs, I would advise a more object-like approach using closures
>like crazy.  By using traditional closures, _standard_ inlining
>optimizations could then achieve the same optimized code that most
>SETF macros achieve.  Furthermore, the non-optimized cases would
>provide for the equivalent of runtime SETF's which are sometimes
>sorely needed.
>

I'm sorry, I don't think this addresses the real problem. There's a
fundamental difference between a top-level object which exists in the
name space, and an anonymous cons cell. It makes a great deal of sense
to have a homogenous way of changing:

	* the value of a variable;
	* the value of a property of some name;
	* the value of an instance variable of some object;
	* the value of a class variable of some class.

All these things are in some sense first class. If anything is hanging
on to a pointer to the value of a variable, it presumably *wants* to
know when that variable changes. Cons cells in arbitrary list
structures are a very different matter. One of the (few) space
efficiencies of LisP is that you don't have to copy until you want to
make changes, and even then you may only have to make a partial copy
of what you're pointing at.

Consequently, in real LisP programs, it's perfectly normal and
legitimate for different objects to hold pointers to the same piece of
structure, in the belief that each 'owns' it. When they want to make a
change, they can make non-destructive changes by CONSing. Only what
is actually changed need be copied. 

If they want to communicate that change, *and under the design
protocols of the system this is legitimate*, they can make destructive
change by RPLAC.

My objection to SETF is that the way it alters list structure is
destructive. As it has become/was intended to become the default way
of changing values (aluminium book p94), LisP beginners will no longer
learn the fundamental software engineering principle outlined above,
so that the perceived power and expressiveness of the language is
impoverished.


-- 
---------simon@rheged.dircon.co.uk
