Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!yeshua.marcam.com!uunet!EU.net!uknet!festival!edcogsci!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Subject: Re: SETF (was Re: Why do people like C? (Was: Comparison: Beta - Lisp))
Message-ID: <CyAM0D.57n@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute-alter.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <Cy3E67.42K@rheged.dircon.co.uk> <Cy5Bv7.JDy@cogsci.ed.ac.uk> <Cy62A5.5G7@rheged.dircon.co.uk>
Date: Wed, 26 Oct 1994 18:29:00 GMT
Lines: 121

In article <Cy62A5.5G7@rheged.dircon.co.uk> simon@rheged.dircon.co.uk (Simon Brooke) writes:
>In article <Cy5Bv7.JDy@cogsci.ed.ac.uk>,
>Jeff Dalton <jeff@aiai.ed.ac.uk> wrote:
>>In article <Cy3E67.42K@rheged.dircon.co.uk> 
>>simon@rheged.dircon.co.uk (Simon Brooke) writes:
>>
>>>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.
>>
>>How about a slot in a modifiable object?  That's a paradigm
>>case, and yet it's not clear that you list it at all.

>Yes, the list was not exhaustive; I could equally have listed an
>element of an array.

My remark was not because you left something out but because
you left something out that was so central.

>>In any case, the things you list are not all "top-level objects
>>which exist in the name space".  For instance, instance vars are
>>local to the object.

>No, that was careless use of language on my part. I'm still failing to
>find the form of words I need. But clearly, none of these things are
>anonymous; each is uniquely accessible by name.

Sure, but that's why your list is so biased.

Here's a fairly normal thing to do that you seem to find suspect:

  Take a list of structs and modify the S slot of each of the
  structs.

Now these structs needn't uniquely accessible by name.  More
to the point, this way of dealing with them doesn't access
them by name.  They're not top-level objects existing in a
name space (unless the programmer has decided to provide
names for all of them in some way, which is not the normal
case for structs but does occur in some AI code).

If you were to say that cons cells should be immutable, that
I could understand.  Lists are most often (I suspect) used in
a way that makes destructive modification confusing and error-
prone.  But your talk of "top-level objects" and so forth is
a different and much more general point.  Moreover, your
complaint about modifying conses is not that they can be
modified but that SETF can be used to do it.  That I find
very odd, and if using SETF this way violates a "fundamental
software engineering principle" I don't know what that
principle might be.

That SETF can be used for conses simply means that conses are
being treated as analogous to

  (defstruct cons car car)

Of course, conses can also be considered objects that have car
and cdr as instance variables.  SETF then sends a message to the
object asking it to change it's car or cdr.

So I have no idea why you think the "fundamental software engineering
principle outlined above" provides any argument whatsoever against
SETF of CAR and CDR.

>>>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.
>>
>>Bull.

See above.

>Jeff, that is not an argument which does you credit. You might argue:
>
>* that a late copying programming style is undesirable for other
>  reasons;
>* that SETF was never intended to become the default way of changing
>  values;
>* that beginners _are_ still taught to use CONS rather than SETF when
>  operating on lists;
>* that destructively altering the values of anonymous cons cells makes
>  debugging more fun;
>* that my real objection to SETF is not what I've stated, but
>  something irrational or religious
>
>or some other argument which I haven't thought of -- in which case I
>might learn something from you, as I often have done in the past.

I don't know what your real reasons are (so to speak), because nothing
you've said so far makes your objection seem reasonable to me.  I'm
reluctant to conclude that your objection is irrational.

Now, for your points above:

 * I don't know what you mean by a "late copying programming style".
 * SETF is the default way of changing slots and the like, but what's
   wrong with that?
 * I've never heard SETF proposed as an alternative to _CONS_.
   Perhaps you meant RPLACA and RPLACD?
 * Destructive modification of conses can cause problems, but not
   because they're anonymous.  Destructive modification of anonymous
   structs is a perfectly ordinary thing to do in most programming
   languages, so far as I can tell.  Objects-with-state can be
   made out of conses just as they can be made out of vectors
   or the typed-vectors that are probably used internally for
   structs.
 * See above.  I could understand the view that conses should
   not be modifiable; but I don't see wny modifying them with
   SETF is what you're focusing on.

-- jeff
