Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!fs7.ece.cmu.edu!hudson.lm.com!godot.cc.duq.edu!newsfeed.pitt.edu!gatech!howland.reston.ans.net!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: <Cynq8I.ItJ@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: <Cy62A5.5G7@rheged.dircon.co.uk> <CyAM0D.57n@cogsci.ed.ac.uk> <CyFE3K.8KL@rheged.dircon.co.uk>
Date: Wed, 2 Nov 1994 20:29:06 GMT
Lines: 112

In article <CyFE3K.8KL@rheged.dircon.co.uk> simon@rheged.dircon.co.uk (Simon Brooke) writes:

Simon --

In this reply, you didn't quote any of my main points, leaving only

  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.

Now you say:

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

Your "fundamental principle" was in terms of "a fundamental difference
between a top-level object which exists in the name space, and an
anonymous cons cell".

But there are lots of anonymous objects in the world.  Consider
a list of structs.  Are we supposed to not change slots in the
structs?

Moreover, the mods you sanction as setf-able, such as assignment to
instance variables, don't rule out setf-ing cars and cdrs, because
conses can be objects with car and cdr as instance variables.

(All this was said in more detail in my earlier article.)

Now, I can see why conses are different from ordinary structs.
They tend to be used in a way that makes destructive modification
more dangerous.  But that's an argument for making them immutable.

You might argue that we can let them be mutable but the operation
that mutates them should be an obscure one.  Indeed, that seems to
be what you're after.  But you didn't cite any fundamental principles
about the relative obscurity of operations.  

In short, I think you're trying to make this issue one of first
principles when it isn't.  It's more a pragmatic, all-things-considered,
maybe this would be better, sort of issue.  It's the way conses are
used, and not some fundamental thing about what they are, that makes
modifying them a distinct case.  

Moreover, there's a fundamental principle, orthogonality, on the side
of always using SETF.

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

They will use SETF rather than RPLACA/D.  But why would they use
it rather than a different programming style?  This looks like a
problem that education can reasonably handle to me.  You seem to
think it's an outrageous perversion that disqualifies Common Lisp
as an acceptable language.

>   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 many Lisps, not just Common Lisp, do more or less the same
thing.  I don't think Common Lisp people chose efficiency over
intuition.  They were simply working within an existing tradition
rather than starting over.

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

There is a fundamental point of philosophy, but it's not the one
you're thinking of.  Common Lisp was more conservative and pragmatic
than, say, Scheme.  For Scheme they adopted T's radical naming
conventions such as a final "!" for destructive operations.
T's conventions were at one time controversial.  In response 
to a remark about T being "so clean, elegant and powerful it 
brings tears to your eyes", we saw:

  Yes, but why call it Lisp?  How about ONION (Onion's Not it's
  Original Name ?)

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

See Richard O'Keefe's article ("SETF-like things were very much in the
air.")

Note too that Franz Lisp is from the west coast and is virtually
the same as MacLisp.  (Don't let some old MacLispers hear you say
this.  Now *that*'s an east-coast / weat-coast difference, if you
like.)

-- jeff
 
