On 30 Jan 91 22:51:06 GMT Barry Margolin <······@think.com> wrote:
>...and I sometimes wish the Common
>Lisp designers had had the guts to get rid of SETQ);...
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?
- Steve Bacher <·······@draper.com>
In article <··························@MVS.DRAPER.COM> ·······@mvs.draper.com writes:
>On 30 Jan 91 22:51:06 GMT Barry Margolin <······@think.com> wrote:
>>...and I sometimes wish the Common
>>Lisp designers had had the guts to get rid of SETQ);...
>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.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
In article <······················@Think.COM> ······@think.com (Barry Margolin) writes:
>A similar argument could be made for
>abolishment of RPLACD and RPLACA.
>--
>Barry Margolin, Thinking Machines Corp.
True, true. But I still prefer to use RPLACD and RPLACA (only very rarely)
because I want the intent well advertised. I tend to skim right over a
(SETF (CAR ...) ...) because it looks like every other SETF in the code.
Jay Nelson (TRW) ···@wilbur.coyote.trw.com
From: Jeff Dalton
Subject: Re: SETQ vs SETF (was Re: Question about INTERN)
Date:
Message-ID: <4094@skye.ed.ac.uk>
In article <······················@Think.COM> ······@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
In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
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
In draft ANSI Common Lisp, the semi-portable way (i.e., via metaobject
accessors agreed upon by major CL vendors) is
(MAPCAR #'CLOS:SLOT-DEFINITION-NAME
(CLOS:CLASS-SLOTS (FIND-CLASS 'STRUCTURE-TYPE-NAME)))
for a structure type called STRUCTURE-TYPE-NAME.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
In article <····@skye.ed.ac.uk> ····@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.
······@think.com
{uunet,harvard}!think!barmar
From: Jeff Dalton
Subject: Re: SETQ vs SETF (was Re: Question about INTERN)
Date:
Message-ID: <4124@skye.ed.ac.uk>
In article <······················@Think.COM> ······@think.com (Barry Margolin) writes:
>In article <····@skye.ed.ac.uk> ····@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.
1. There are only a few cases (eg, LDB) that need SETF to be a macro.
This aspect of SETF is hard to understand, as the discussion of
some of the cleanup issues showed.
2. If the functional approach were used, the compiler could still
expand and compile SETFs in-line.
3. The functional appraoch is simpler and gives us names for the
setter functions, which would often be useful. Moreover, it
does it without adding a mess of new symbols to the LISP package.
>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).
Nor have I. But I think PUSH and ROTATEF can use SETF as a black
box, without having to get inside it (except maybe in the same small
number of cases where SETF has to be a macro).
So, let SETF be a macro, but also provide a standard way to name
the setter functions. I think that in this case one can have the
best of both worlds, so to speak.
>>The idea that Lisp is full of redundancies because of mapping vs
>>DO vs LOOP, etc, seems to me a bit strange. ... [comparison with C
>>deleted].
>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 you're right about putc, but I was thinking (or would have
been if I'd been thinking more clearly) more of puts (for writing
strings) and the claim (sometimes made) that people should never use
printf unless they really have to. I probably should have compared
printf to format as well.
Moreover, I don't think do-list and mapc are a redundancy, because
mapc is in a sense more general.
>>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.
I agree. And the ability to extract a relatively simple kernel is
important to users because (a) it provides a conceptual simplification,
(b) it makes it more likely that the size of implementations can be
controlled.
Indeed, when saying primitives were missing, I meant it from the
user's point of view. Implementations can have whatever primitives
they want, but it doesn't necessarily do the users any good.
>In general, primitives are missing because they would
>probably only be used to implement the higher-level facilities.
And it's a mistake to suppose that users will not want to build
similar higher-level facilities that are slightly but importantly
different.
>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.
See above. Call it (SETF GET) or (SETTER GET) rather than PUTPROP.
-- jd