In article <············@early-bird.think.com> ······@think.com (Barry Margolin) writes:
No, there's only a MULTIPLE-VALUE-SETQ.
In hindsight, having separate SETQ and SETF was a bad design, IMHO.
I agree. In a Lisp style guide I wrote the general rule was to use the
most specific construct when choosing among several alternative ways
of doing the same thing. But, when it came to SETF vs. SETQ I
recommended using SETF all the time.
One argument for using SETQ could be that it is easier to spot which
uses are fast-simple-variable access, compared to
slow-complicated-slot access where SETF should be used. But with
SYMBOL-MACROLET you can be fooled by an innocent SETQ, because it, as
I understand, is treated like a SETF.
One thing that annoys me is that one can't use #'(setf
struct-slot-reader) because struct-slot setters can be implemented as
setf-macros and not as methods. BTW, are they allowed to be methods?
Perhaps one should be able to choose?
Is SETF an inovation of Common Lisp? When was it conceived? Anyhow,
well done.
--
Hallvard Traetteberg
Dept. of Knowledge Based Systems
SINTEF SI (Center for Industrial Research)
Box 124 Blindern, 0314 Oslo 3
NORWAY
Tlf: +47 2 45 29 83 or +47 2 45 20 10
Fax: +47 2 45 20 40
Email: ···················@si.no
In article <·················@monsun.si.no> ···@si.no (Hallvard Tretteberg) writes:
>But, when it came to SETF vs. SETQ I
>recommended using SETF all the time.
I still can't get out of the habit of using SETQ for variables, but that
may just mark me as an old fuddy-duddy. :-)
>One thing that annoys me is that one can't use #'(setf
>struct-slot-reader) because struct-slot setters can be implemented as
>setf-macros and not as methods. BTW, are they allowed to be methods?
>Perhaps one should be able to choose?
It's unspecified how they're implemented, and there's almost certainly
diversity in current implementations.
>Is SETF an inovation of Common Lisp? When was it conceived? Anyhow,
>well done.
I think it was introduced to Maclisp in the mid 70's as an adjunct to
DEFSTRUCT. It was a standard feature of Zetalisp and probably also NIL.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
In article <·················@monsun.si.no> ···@si.no (Hallvard Tretteberg) writes:
>... But, when it came to SETF vs. SETQ I
>recommended using SETF all the time.
Why? I'm in the dark about this. Is the idea that the compiler
converts
(setf sym val)
to something equivalent to
(setq sym val)
, so that both forms are equally fast? In interpreted code,
would you recommend SETQ, since, I would suppose, it would be faster
there?
Thanks.
Marshall Abrams
In article <······················@midway.uchicago.edu> ····@midway.uchicago.edu writes:
>In article <·················@monsun.si.no> ···@si.no (Hallvard Tretteberg) writes:
>>... But, when it came to SETF vs. SETQ I
>>recommended using SETF all the time.
>
>Why? I'm in the dark about this. Is the idea that the compiler
>converts
> (setf sym val)
>to something equivalent to
> (setq sym val)
>, so that both forms are equally fast?
Yes. SETF is a macro, so it must be converted at compile time to some
equivalent code. While it's conceivable that a stupid implementation could
expand it into something slower than the equivalent SETQ, it seems pretty
unlikely.
> In interpreted code,
>would you recommend SETQ, since, I would suppose, it would be faster
>there?
The interpreter is slow enough that the difference between the two of these
is in the noise. No one who cares about performance uses interpreted code.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar