Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: SETQ vs SETF (was Re: Question about INTERN)
Message-ID: <4094@skye.ed.ac.uk>
Date: 11 Feb 91 17:50:02 GMT
References: <NETMAILR11013108350SEB1525@MVS.DRAPER.COM> <1991Jan31.180524.21828@Think.COM>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 56

In article <1991Jan31.180524.21828@Think.COM> barmar@think.com (Barry Margolin) writes:

>>Do you mean that you wish that SETQ had been flushed in favor of SETF,
>>or that side-effecting variables via assignment should have been
>>prohibited?
>
>SETQ should have been flushed in favor of SETF.
>
>In fact, except for error checking purposes, there's no reason SETQ and
>SETF couldn't have been made synonymous.  SETF was originally an optional
>macro package in MacLisp, and it needed SETQ to be kept around so that it
>had something to expand into, as well as for compatibility with programs
>that examine other programs.  However, in Common Lisp it is a required
>primitive, and there is no rule that says that SETF has to expand into a
>call to a documented function (e.g. there's no documented function for SETF
>of AREF to expand into).  Instead of making SETF part of the language, they
>could simply have extended SETQ to allow generalized variables where it
>currently only allows regular variables.
>
>These are the kinds of things Lisp-bashers are referring to when they
>complain that Lisp is full of redundancies (actually, they're more often
>referring to the redundancy of having sequence functions, mapping
>functions, the DO family, and LOOP).  A similar argument could be made for
>abolishment of RPLACD and RPLACA.

I think one of the problems with Common Lisp is that a number of
functions that must be logically present aren't there in practice
or else vary from implementation to implementation.  For example,
there's no portable way to find out what slots a defstruct has
even though the information ust be there for printing.  This means
that when you define a :print-function it's difficult to make it
print in the default way in the cases where that's what you want.

I think it would be better if SETF worked more like SET does in T.
That is, (SETF (accessor ,@access-args) value) would expand to
something like ((SETTER accessor) ,@access-args value).  That is
there would be set-function, and they'd be called (in effect)
(SETTER accessor).  Something like this was done for CLOS, where
(SETF accessor) is a way to name the setter.  But (last time I
checked) this hadn't been propegated consistently though the
language.

The idea that Lisp is full of redundancies because of mapping vs
DO vs LOOP, etc, seems to me a bit strange.  I agree that this
is something many people identify as a problem.  But ther is
similar redundancy in C.  You can use lower-level routines 
instead of "printf"; you can write loops with "for" or "while";
and the mapping functions would be useful too, if they were
present, and if they could be written in a sufficiently general
way (which the type system doesn't allow).

I think a more serious problem with CL is that it's hard to
extract a relatively simple kernel because some of the primitives
are missing.

-- jd