Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!hookup!news.moneng.mei.com!howland.reston.ans.net!pipex!dircon!rheged!simon
From: simon@rheged.dircon.co.uk (Simon Brooke)
Subject: Re: SETF (was Re: Why do people like C? (Was: Comparison: Beta - Lisp))
Message-ID: <CyFE3K.8KL@rheged.dircon.co.uk>
Organization: none. Disorganization: total.
References: <Cy3E67.42K@rheged.dircon.co.uk> <Cy5Bv7.JDy@cogsci.ed.ac.uk> <Cy62A5.5G7@rheged.dircon.co.uk> <CyAM0D.57n@cogsci.ed.ac.uk>
Date: Sat, 29 Oct 1994 08:26:07 GMT
Lines: 133

In article <CyAM0D.57n@cogsci.ed.ac.uk>,
Jeff Dalton <jeff@aiai.ed.ac.uk> wrote:
>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:
>
much excerpted: first bit here is Jeff

>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

I don't know whether it's simply that I am expressing myself extremely
badly, or also that you are being wilfully obtuse. You do perfectly
well see the 'fundamental principle' I refer to: it's the principle
that you don't destructively change what you don't own.

Certainly a CONS cell is just a structure with two slots. But the way
it is used is different to the way in which other structures are
typically used.

Certainly SETF has the _effect_ of RPLACAD when used on a CONS cell.
However, RPLACAD are things known-to-be-dangerous: when I was taught
LisP, and when I have taught LisP, the principle has been 'don't do
this until you know what you are doing'.

But SETF is _generalised_ assignment. Beginners learn it (as they are
intended to learn it) as 'the way you alter things in LisP'.
Consequently, my concern is that they will use it by default, even
where it is dangerous to do so, rather than using structure copying.

Interestingly, on another thread in this group at present, we come
across a practical example of someone getting into difficulty with an
analogous problem:

On 26 Oct 1994, Michael Dent wrote:
> ....
> * (setq temp '(3 5 2 4 7 8))
> Warning:  Declaring TEMP special.
> 
> (3 5 2 4 7 8)
> * (sort temp '<)
> 
> (2 3 4 5 7 8)
> * temp
> 
> (3 4 5 7 8)   !!

Michael had clearly missed the fact that SORT '...may destructively
modify argument sequences...'. Consequently his variable points to a
cell which after modification is no longer the head of the sorted
list. My intuition, like Michael's, is to assume that if I pass a list
to a function as argument, my list isn't normally going to be smashed
by that function. Obviously there are efficiency costs underlying this
assumption. It isn't unreasonable that the Common LISP people chose
efficiency over intuition, given that they do clearly state which
functions may destructively modify arguments.

But there is a fundamental point of philosophy here. My preference is
that the default way of doing things should be safe but slow, and that
there should be an alternative, clearly labelled, way of doing the
quick-and-dirty for people who know what they're about. Perhaps in
some future LisP standard, we might adopt a convention of appending a
'D' to the name of a function which destructively modifies its
arguments, just as we now append a 'P' (or in other LisP family
languages a '?') to the names of functions which are predicates. Thus
we might have a pair:

(SORT <list> <predicate> <key>)		... does structure copying
(SORTD <list> <predicate> <key>)	... does structure modification

Interestingly, to return briefly to the original discussion (and NO! I
do NOT want to continue it), this difference in philosophy was (as I
recall: correct me by mail if I'm wrong) reflected in the difference
between Interlisp and the east-coast LisPs.

-- 
--------simon@rheged.dircon.co.uk
	(cond ((think you (oddp (my 'car)))
	       (should (see you (my 'cdr)))))
