From: Peter Seibel
Subject: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <m31y0o8ry0.fsf@localhost.localdomain>
So I'm trying to find a good way to explain the naming of the five
functions/macros/special forms: GET, SET, GETF, SETF, and SETQ. For
starters, what does the 'F' in GETF and SETF stand for? Is it even the
same thing in those two functions? I've always thought of the 'Q' in
SETQ as standing for "quoted", as in you don't have to quote the
symbol. But while that's a reasonable mnemonic for a beginning Lisp
programmer, it's dangerously simplistic: I got caught by it the other
day when I told someone that that (setq foo x) was equivalent to (set
'foo x) which is only true, of course, when x is special.

Also, if someone wants to give me a little history lesson, I'd love to
get a point of view that will help me get over my discomfort with GET
and SET not being more closely related and likewise GETF/SETF. I.e.
with my current point of view (which is, no doubt, Java-induced brain
damage) I'd expect GET to access a value set with SET and likewise
GETF/SETF. But of course that's not what they mean in Lisp. Which is
fine. I'm just curious how those different functions/macros/special
functions came into being.

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

  The intellectual level needed   for  system design is  in  general
  grossly  underestimated. I am  convinced  more than ever that this
  type of work is very difficult and that every effort to do it with
  other than the best people is doomed to either failure or moderate
  success at enormous expense. --Edsger Dijkstra

From: Paul F. Dietz
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <Ha-dnZD71q0T-BqjXTWcoQ@dls.net>
Peter Seibel wrote:

> But while that's a reasonable mnemonic for a beginning Lisp
> programmer, it's dangerously simplistic: I got caught by it the other
> day when I told someone that that (setq foo x) was equivalent to (set
> 'foo x) which is only true, of course, when x is special.

SETQ originated before lisps had lexically scoped variables.

	Paul
From: Peter Seibel
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <m3smt47b5z.fsf@localhost.localdomain>
"Paul F. Dietz" <·····@dls.net> writes:

> Peter Seibel wrote:
> 
> > But while that's a reasonable mnemonic for a beginning Lisp
> > programmer, it's dangerously simplistic: I got caught by it the other
> > day when I told someone that that (setq foo x) was equivalent to (set
> > 'foo x) which is only true, of course, when x is special.
> 
> SETQ originated before lisps had lexically scoped variables.

So it really was a synonym for (set 'foo x)?

-Peter


-- 
Peter Seibel                                      ·····@javamonkey.com

  The intellectual level needed   for  system design is  in  general
  grossly  underestimated. I am  convinced  more than ever that this
  type of work is very difficult and that every effort to do it with
  other than the best people is doomed to either failure or moderate
  success at enormous expense. --Edsger Dijkstra
From: Barry Margolin
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <oN2ia.11$hx1.266@paloalto-snr1.gtei.net>
In article <··············@localhost.localdomain>,
Peter Seibel  <·····@javamonkey.com> wrote:
>"Paul F. Dietz" <·····@dls.net> writes:
>
>> Peter Seibel wrote:
>> 
>> > But while that's a reasonable mnemonic for a beginning Lisp
>> > programmer, it's dangerously simplistic: I got caught by it the other
>> > day when I told someone that that (setq foo x) was equivalent to (set
>> > 'foo x) which is only true, of course, when x is special.
>> 
>> SETQ originated before lisps had lexically scoped variables.
>
>So it really was a synonym for (set 'foo x)?

Yes.

-- 
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Pascal Costanza
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <costanza-BDD4BA.01271331032003@news.netcologne.de>
In article <··············@localhost.localdomain>,
 Peter Seibel <·····@javamonkey.com> wrote:

> So I'm trying to find a good way to explain the naming of the five
> functions/macros/special forms: GET, SET, GETF, SETF, and SETQ. For
> starters, what does the 'F' in GETF and SETF stand for? Is it even the
> same thing in those two functions?

I don't know about the origin of get and getf. The f in setf stands for 
"form", and its intended meaning is (setf form value) => in the future, 
let form result in value (and form is intended to mean "any form").

> I've always thought of the 'Q' in
> SETQ as standing for "quoted", as in you don't have to quote the
> symbol. But while that's a reasonable mnemonic for a beginning Lisp
> programmer, it's dangerously simplistic: I got caught by it the other
> day when I told someone that that (setq foo x) was equivalent to (set
> 'foo x) which is only true, of course, when x is special.

I've been told by Richard Gabriel (in a mailing list) that (setq foo x) 
is indeed just an "abbreviation" for (set 'foo x) - which I found a bit 
puzzling because you actually don't save any keystrokes.

Why does the equivalence only hold when x is special?!?


Pascal

-- 
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
From: Matthew Danish
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <20030330201325.B23255@lain.cheme.cmu.edu>
On Mon, Mar 31, 2003 at 01:27:13AM +0200, Pascal Costanza wrote:
> is indeed just an "abbreviation" for (set 'foo x) - which I found a
> bit puzzling because you actually don't save any keystrokes.  Why does
> the equivalence only hold when x is special?!?

Because SET changes the symbol-value of the given symbol.  SET is also a
function; which is obviously unacceptable for setting lexical variables,
since the name of the lexical variable can disappear after compilation.

-- 
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Peter Seibel
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <m3d6k873gf.fsf@localhost.localdomain>
Pascal Costanza <········@web.de> writes:

> I don't know about the origin of get and getf. The f in setf stands
> for "form", and its intended meaning is (setf form value) => in the
> future, let form result in value (and form is intended to mean "any
> form").

That makes sense. At least it's a reasonable mnemonic.

> I've been told by Richard Gabriel (in a mailing list) that (setq foo
> x) is indeed just an "abbreviation" for (set 'foo x) - which I found
> a bit puzzling because you actually don't save any keystrokes.

Yeah. But it saves you from having to understand symbols quite as
deeply. Which is useful for beginners. At least it was for me.

> Why does the equivalence only hold when x is special?!?

Because (from the SET dictionary entry):

  (set symbol value) ==  (setf (symbol-value symbol) value)

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

  The intellectual level needed   for  system design is  in  general
  grossly  underestimated. I am  convinced  more than ever that this
  type of work is very difficult and that every effort to do it with
  other than the best people is doomed to either failure or moderate
  success at enormous expense. --Edsger Dijkstra
From: Pierpaolo BERNARDI
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <31Nha.45869$i26.1374584@news2.tin.it>
"Pascal Costanza" <········@web.de> ha scritto nel messaggio ···································@news.netcologne.de...

> I've been told by Richard Gabriel (in a mailing list) that (setq foo x) 
> is indeed just an "abbreviation" for (set 'foo x) 

Probably he meant that the origin is that.

- which I found a bit 
> puzzling because you actually don't save any keystrokes.

But you save a cons cell.

> Why does the equivalence only hold when x is special?!?

Because for lexicals it does not even make sense.

P.
From: Pascal Costanza
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <b6929l$rjq$1@f1node01.rhrz.uni-bonn.de>
Pascal Costanza wrote:

> I've been told by Richard Gabriel (in a mailing list) that (setq foo x) 
> is indeed just an "abbreviation" for (set 'foo x) - which I found a bit 
> puzzling because you actually don't save any keystrokes.

I haven't put the pieces properly together: I recall reading in "The Art 
of the Interpreter" that in the beginning, Lisp didn't have the ' 
syntax, so you could only write (set (quote x) val). Then indeed, (setq 
x val) is an abbreviation.


Pascal

-- 
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Kaz Kylheku
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <cf333042.0303311703.69bc4d77@posting.google.com>
Pascal Costanza <········@web.de> wrote in message news:<············@f1node01.rhrz.uni-bonn.de>...
> Pascal Costanza wrote:
> 
> > I've been told by Richard Gabriel (in a mailing list) that (setq foo x) 
> > is indeed just an "abbreviation" for (set 'foo x) - which I found a bit 
> > puzzling because you actually don't save any keystrokes.
> 
> I haven't put the pieces properly together: I recall reading in "The Art 
> of the Interpreter" that in the beginning, Lisp didn't have the ' 
> syntax, so you could only write (set (quote x) val). Then indeed, (setq 
> x val) is an abbreviation.

That's right; the etymology of SETQ is clearly that it originated as
that abbreviation, whose equivalence no longer holds.

In the beginning, Lisp not only had the ' syntax, but it also had no
lexical scope, so val would have necessarily been a dynamic variable.

Anyone know when symbol macros were introduced, incidentally?
From: Nils Goesche
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <lypto6zkf5.fsf@cartan.de>
···@ashi.footprints.net (Kaz Kylheku) writes:

> Anyone know when symbol macros were introduced, incidentally?

Weren't they specifically invented to make WITH-SLOTS possible?

Regards,
-- 
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x0655CFA0
From: Kaz Kylheku
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <cf333042.0304010552.5d039cd9@posting.google.com>
Nils Goesche <······@cartan.de> wrote in message news:<··············@cartan.de>...
> ···@ashi.footprints.net (Kaz Kylheku) writes:
> 
> > Anyone know when symbol macros were introduced, incidentally?
> 
> Weren't they specifically invented to make WITH-SLOTS possible?

I doubt that; more likely, WITH-SLOTS was invented as an excuse to put
in symbol macros. ;)
From: Barry Margolin
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <m0iia.3$af5.307@paloalto-snr1.gtei.net>
In article <····························@posting.google.com>,
Kaz Kylheku <···@ashi.footprints.net> wrote:
>Nils Goesche <······@cartan.de> wrote in message
>news:<··············@cartan.de>...
>> ···@ashi.footprints.net (Kaz Kylheku) writes:
>> 
>> > Anyone know when symbol macros were introduced, incidentally?
>> 
>> Weren't they specifically invented to make WITH-SLOTS possible?
>
>I doubt that; more likely, WITH-SLOTS was invented as an excuse to put
>in symbol macros. ;)

No, I think Nils was right.

WITH-SLOTS and WITH-ACCESSORS were created to emulate other OO languages'
ability to access instance variables as normal variables within a class's
methods.  Rather than make these be special forms that worked magically
with CLOS, we invented symbol macros as a generalization.

For a while I think we even had DEFINE-SYMBOL-MACRO, which created
top-level symbol macros.  But we decided that since they were really only
for things like WITH-SLOTS, SYMBOL-MACROLET was sufficient.

-- 
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Kent M Pitman
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <sfwu1difc23.fsf@shell01.TheWorld.com>
Barry Margolin <··············@level3.com> writes:

> For a while I think we even had DEFINE-SYMBOL-MACRO, which created
> top-level symbol macros.

No, it came later in CL.  But if memory serves (since my lispm manuals
are in a storage room), the LispM had DEFINE-SYMBOL-MACRO before CL
which may be why your memory has it the other way around.

> But we decided that since they were really only
> for things like WITH-SLOTS, SYMBOL-MACROLET was sufficient.

In CL, yes, for a while.  But not forever.  I proposed adding
DEFINE-SYMBOL-MACRO to CL because it was on the short list of
substrates that the lispm had that CL did not that were required to
portably implement ISLISP in CL [you needed it to implement both
lexicals and the odd kind of defconstant that ISLISP has (which is
like CL's defconstant globally but which lets you bind the thing
locally)].
From: Christophe Rhodes
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <sqhe9ii36g.fsf@lambda.jcn.srcf.net>
Barry Margolin <··············@level3.com> writes:

> For a while I think we even had DEFINE-SYMBOL-MACRO, which created
> top-level symbol macros.  But we decided that since they were really only
> for things like WITH-SLOTS, SYMBOL-MACROLET was sufficient.

Well, if you decided that, you didn't decide very hard:

  Macro DEFINE-SYMBOL-MACRO

  Description:

  Provides a mechanism for globally affecting the macro expansion of
  the indicated symbol.  [...]

(not that I'm particularly complaining about the existence of
DEFINE-SYMBOL-MACRO).

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Pascal Costanza
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <b6cbrf$tgm$1@f1node01.rhrz.uni-bonn.de>
Barry Margolin wrote:
> In article <····························@posting.google.com>,
> Kaz Kylheku <···@ashi.footprints.net> wrote:
> 
>>Nils Goesche <······@cartan.de> wrote in message
>>news:<··············@cartan.de>...
>>
>>>···@ashi.footprints.net (Kaz Kylheku) writes:
>>>
>>>
>>>>Anyone know when symbol macros were introduced, incidentally?
>>>
>>>Weren't they specifically invented to make WITH-SLOTS possible?
>>
>>I doubt that; more likely, WITH-SLOTS was invented as an excuse to put
>>in symbol macros. ;)
> 
> 
> No, I think Nils was right.
> 
> WITH-SLOTS and WITH-ACCESSORS were created to emulate other OO languages'
> ability to access instance variables as normal variables within a class's
> methods.  Rather than make these be special forms that worked magically
> with CLOS, we invented symbol macros as a generalization.
> 
> For a while I think we even had DEFINE-SYMBOL-MACRO, which created
> top-level symbol macros.  But we decided that since they were really only
> for things like WITH-SLOTS, SYMBOL-MACROLET was sufficient.

Well, define-symbol-macro _is_ in the standard. ;)

And I think it's useful...


Pascal

-- 
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Barry Margolin
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <6xiia.6$af5.420@paloalto-snr1.gtei.net>
In article <············@f1node01.rhrz.uni-bonn.de>,
Pascal Costanza  <········@web.de> wrote:
>Barry Margolin wrote:
>> For a while I think we even had DEFINE-SYMBOL-MACRO, which created
>> top-level symbol macros.  But we decided that since they were really only
>> for things like WITH-SLOTS, SYMBOL-MACROLET was sufficient.
>
>Well, define-symbol-macro _is_ in the standard. ;)

Oops, I had it backwards.  For a while we *only* had SYMBOL-MACROLET,
because we thought it was only needed for the WITH-xxx macros.  Then we
decided to generalize it even more.

-- 
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Kaz Kylheku
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <cf333042.0303311659.21a8cef4@posting.google.com>
Pascal Costanza <········@web.de> wrote in message news:<······························@news.netcologne.de>...
> I've been told by Richard Gabriel (in a mailing list) that (setq foo x) 
> is indeed just an "abbreviation" for (set 'foo x) - which I found a bit 
> puzzling because you actually don't save any keystrokes.

SETQ has different semantics from SET. It works with lexical
variables, whereas SET works only with the SYMBOL-VALUE of a symbol.
SETQ also works across symbol-macrolet; it automagically turns into a
SETF. For instance:

  (symbol-macrolet ((third-cell (aref a i)))
    (setq third-cell 42)) ;; same as (setf (aref a i) 32)

> Why does the equivalence only hold when x is special?!?

Because SET is a function. That function cannot see your lexical
environment, and so cannot tell that third-cell is a local symbol
macro or lexical variable.

This is analogous to EVAL; the form processed by EVAL also cannot see
the lexical environment in which the EVAL is called. You could ask,
why does:

   (eval `(foo ,@bar))

work like

   (apply #'foo bar)

only when bar is special? :)
From: Barry Margolin
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <23iia.4$af5.319@paloalto-snr1.gtei.net>
In article <····························@posting.google.com>,
Kaz Kylheku <···@ashi.footprints.net> wrote:
>Pascal Costanza <········@web.de> wrote in message
>news:<······························@news.netcologne.de>...
>> I've been told by Richard Gabriel (in a mailing list) that (setq foo x) 
>> is indeed just an "abbreviation" for (set 'foo x) - which I found a bit 
>> puzzling because you actually don't save any keystrokes.
>
>SETQ has different semantics from SET. It works with lexical
>variables, whereas SET works only with the SYMBOL-VALUE of a symbol.
>SETQ also works across symbol-macrolet; it automagically turns into a
>SETF.

None of these differences were relevant at the time that the name was
created over 40 years ago.  Lexical variables weren't added until some
dialects in the late 70's, and symbol macros weren't added until CLOS was
added by X3J13 in the late 80's.

-- 
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Barry Margolin
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <GP2ia.12$hx1.110@paloalto-snr1.gtei.net>
In article <······························@news.netcologne.de>,
Pascal Costanza  <········@web.de> wrote:
>I've been told by Richard Gabriel (in a mailing list) that (setq foo x) 
>is indeed just an "abbreviation" for (set 'foo x) - which I found a bit 
>puzzling because you actually don't save any keystrokes.

You did in the days when it was (set (quote foo) x).  I think SETQ may
predate the ' reader macro.

>Why does the equivalence only hold when x is special?!?

SET is an ordinary function, so it operates on the symbol's value cell, not
the variable's lexical value.

-- 
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Pierpaolo BERNARDI
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <VYMha.45867$i26.1374083@news2.tin.it>
"Peter Seibel" <·····@javamonkey.com> ha scritto nel messaggio ···················@localhost.localdomain...

> So I'm trying to find a good way to explain the naming of the five
> functions/macros/special forms: GET, SET, GETF, SETF, and SETQ. For
> starters, what does the 'F' in GETF and SETF stand for? 

In SETF it stands for field.

> Is it even the same thing in those two functions? 

Not sure.

> I've always thought of the 'Q' in
> SETQ as standing for "quoted", as in you don't have to quote the
> symbol. But while that's a reasonable mnemonic for a beginning Lisp
> programmer, it's dangerously simplistic: I got caught by it the other
> day when I told someone that that (setq foo x) was equivalent to (set
> 'foo x) which is only true, of course, when x is special.

The name SETQ comes from a time when all variables were special.
Some lisps also had SETQQ.

P.
From: Kent M Pitman
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <sfwsmt3ya36.fsf@shell01.TheWorld.com>
Peter Seibel <·····@javamonkey.com> writes:

> So I'm trying to find a good way to explain the naming of the five
> functions/macros/special forms: GET, SET, GETF, SETF, and SETQ. For
> starters, what does the 'F' in GETF and SETF stand for? Is it even the
> same thing in those two functions? I've always thought of the 'Q' in
> SETQ as standing for "quoted", as in you don't have to quote the
> symbol. But while that's a reasonable mnemonic for a beginning Lisp
> programmer, it's dangerously simplistic: I got caught by it the other
> day when I told someone that that (setq foo x) was equivalent to (set
> 'foo x) which is only true, of course, when x is special.
> 
> Also, if someone wants to give me a little history lesson, I'd love to
> get a point of view that will help me get over my discomfort with GET
> and SET not being more closely related and likewise GETF/SETF. I.e.
> with my current point of view (which is, no doubt, Java-induced brain
> damage) I'd expect GET to access a value set with SET and likewise
> GETF/SETF. But of course that's not what they mean in Lisp. Which is
> fine. I'm just curious how those different functions/macros/special
> functions came into being.

As I recall it...

A long time ago, Lisp was only dynamic.  SET and SETQ were very similar
then, because setting dynamic variables was the same as doing what we
now call
 (SETF (SYMBOL-VALUE 'VAR) 'VAL)
At that time, we called that operation
 (SET 'VAR 'VAL)
sometimes even written
 (SET' VAR 'VAL)
but ultimately written
 (SETQ VAR VAL)
And since it was rare to compute the value, most people only ever saw
SETQ used and never saw SET used.

With the introduction of lexical variables, assignment continued to use
the operator SETQ, but it was no longer equivalent to SET'.

Someone later invented SETF ("Set field") as a generic way of assigning
data structures, to mirror the l-value assignment of other languages.
e.g.,  car(x) := y; would be written (setf (car x) y).  For syntactic
(if not semantic) symmetry, they made x := y be writable as (setf x y).

GET existed pretty much forever as a way of getting things from property
lists.  The asignment operator was (PUTPROP sym val ind).  Some Lisp
dialects used GETPROP instead of GET.  

When SETF came along, (PUTPROP x y z) was subsumed by (SETF (GET x z) y),
which most people considered more visually simple but a better arg order.

People also started to think about the idea of GET being generalized
for so-called "disembodied property lists".  GETF was intended to be
the GET-like way to talk about the field of a property list,
independently of whether the property list was stored on a symbol's plist.
(GETF (PLIST x) y) was the same as (GET x y); later PLIST became SYMBOL-PLIST.

That's more or less the history.

Many people suggest that you should always just teach SETF and never SETQ.
That simplifies some things.  If you've ever _implemented_ a SETF, you'll
notice that SETQ is totally different in semantic nature than other things
assigned by SETF.  As a consequence, I like to think about SETQ as the 
lower-level primitive.  [There's a kind of circular mess that got created
when SYMBOL-PLIST came along, though, because SETQ expands to SETF in the
case of the 'variable' being a 'symbol macro'.  So a true treatment of
SETQ can't treat SETQ as subprimitive, without there being two SETQ's.
And maybe that's just not worth the bother.  I still use SETQ to assign
variables again because it seems 'simpler' to me.]

I and others also suggest you not teach SET.  It's never needed. Just use
SETF of SYMBOL-VALUE.  It's not quite as easy as SET in the case of having
to pass a funarg, as to APPLY, FUNCALL, or MAP but it's rare to need to
do that.  I think SET should atrophy and be removed with time so it can be
recycled in a future dialect for creating sets a la SET-DIFFERENCE, etc.
That would be a better use.  But there are so many uses of SET in 
'The Literature' that this is unlikely to happen. A lot of Lisp is about
its proud history.

People will sometimes suggest not using GET, too, claiming that
toplevel symbols are 'evil' and the like.  Those people are coming
from Scheme or a Scheme-like background that is absent certain things
that CL has (like packages) and are not understanding that the CL
package name makes it reliable to use properties. Using properties is
generally an entirely reasonable thing to do in CL for static data, I
think.  (I wouldn't use it much for things that change in programs
becuase the interlocking of property lists under multitasking is 
beyond the scope of the spec, and largely ill-defined by implementations.)
Non-lipers will suggest you use hash tables instead of properties,
but I think hash tables are likely to be slower.
 (GET 'X 'Y)
takes only one instruction, generally, to get to X's plist, and then
is probably as efficient as a search of the hash bucket that GETHASH
would find.  I think of GET as being a way of bypassing the cost of 
the hashing in a hash table, since in effect things are pre-hashed by
the reader having selected those symbols.

If you never use SET and SETQ, your question reduces to: How do I explain
GET, GETF, and SETF.  The answer is that SETF is how you assign things,
GETF is how you get things from a list; this "F" is lost in history and
I'd encourage people to mostly ignore it--which people are capable of doing.
It had that same 'field' connotation as SETF had, and it was intended to
be a friendly companion to SETF, but its meaning as a part of a word is
different than the meaning of SETF, and so ultimately it's confusing in
spite of its good intent.

One might want to advocate teaching only GETF and teaching GET as
GETF of SYMBOL-PLIST.  That's not entirely awful.  That leaves only GETF
and SETF to explain, which is maybe even easier.

Ultimately, the reason the names are not more regular is that they
were added over a long period of time, compatibly, without disrupting
things in the language that didn't need fixing.  We could stop and fix
things, which would make the language a tiny bit easier to understand,
at the cost of millions of dollars (literally) to the industry for
fixing all the places we broke in so doing.  We're a language about
stability, and that's not our way.
From: Duane Rettig
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <4istzo4l1.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:

> assigned by SETF.  As a consequence, I like to think about SETQ as the 
> lower-level primitive.  [There's a kind of circular mess that got created
> when SYMBOL-PLIST came along, though, because SETQ expands to SETF in the
========^^^^^^^^

I think you meant SYMBOL-MACRO here, and indeed you say symbol-macro a
little later.  I'm not in the habit of correcting typos, but in this
case you are using SYMBOL-PLIST when I think you meant something else,
whereas elsewhere in your article you do use SYMBOL-PLIST as I would
have dine.  So I am pointing it out to avoid confusion by readers.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Thomas F. Burdick
Subject: Re: Naming of GET, SET, GETF, SETF, and SETQ.
Date: 
Message-ID: <xcv4r5jbco3.fsf@avalanche.OCF.Berkeley.EDU>
Kent M Pitman <······@world.std.com> writes:

> People will sometimes suggest not using GET, too, claiming that
> toplevel symbols are 'evil' and the like.  Those people are coming
> from Scheme or a Scheme-like background that is absent certain things
> that CL has (like packages) and are not understanding that the CL
> package name makes it reliable to use properties. Using properties is
> generally an entirely reasonable thing to do in CL for static data, I
> think.  (I wouldn't use it much for things that change in programs
> becuase the interlocking of property lists under multitasking is 
> beyond the scope of the spec, and largely ill-defined by implementations.)
> Non-lipers will suggest you use hash tables instead of properties,
> but I think hash tables are likely to be slower.
>  (GET 'X 'Y)
> takes only one instruction, generally, to get to X's plist, and then
> is probably as efficient as a search of the hash bucket that GETHASH
> would find.  I think of GET as being a way of bypassing the cost of 
> the hashing in a hash table, since in effect things are pre-hashed by
> the reader having selected those symbols.

Plus, another advantage of using GET versus a symbol-keyed hash table,
is that it doesn't prevent your keys and values from being GC'd.  If
you really need a weak hash table, some implementations support them,
but it's even easier to avoid creating those unnecessary references in
the first place.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'