Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: SETQ vs SETF (was Re: Question about INTERN)
Message-ID: <1991Feb13.041244.17473@Think.COM>
Date: 13 Feb 91 04:12:44 GMT
References: <NETMAILR11013108350SEB1525@MVS.DRAPER.COM> <1991Jan31.180524.21828@Think.COM> <4094@skye.ed.ac.uk>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 55

In article <4094@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>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.

It hasn't been propogated because it doesn't provide as much functionality
as the current mechanism, based on DEFINE-SETF-METHOD.  By using a macro,
rather than a functional, style we allow SETF to perform more elaborate
transformations when necessary, and also to perform more of the work at
compile time.  Furthermore, I believe it provides better support for the
macros built on SETF, such as PUSH and ROTATEF; I think a functional
approach might need separate PUSHER and ROTATER functions (but I admit that
I haven't thought about this very hard).

>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 the redundancy complaint is due to the fact that there are several
almost equivalent facilities at about the same level of abstraction.
printf() and putc() are clearly at different levels, while DO-LIST and
MAPC are nearly interchangeable.

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

CL intentionally contains the facilities needed by the *users*, not the
implementors.  In general, primitives are missing because they would
probably only be used to implement the higher-level facilities.  Of course,
if the primitives were there I'm sure people would use them; on the other
hand, the language would be even bigger (and the current draft of the
standard is already about 1300 pages long).  I would rather see us *remove*
RPLACA, RPLACD, and SET (since their main purpose is for SETF to expand
into) rather than to add back ASET and PUTPROP.  Yes, there are some
missing primitives (I think we've added some in the last few years, such as
exposing the pretty-printer, lexical environments, and compiler
optimization), but I won't claim that we've filled in all the gaps.  But we
don't add primitives just for their own sake -- we look at the needs of the
users.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar