What's the difference between setq and setf? Both of them seem
to set up variables. For example (using Clisp):

[69]> (setf hello 'world)
WORLD
[70]> (setq foo 'bar)
BAR
[71]> hello
WORLD
[72]> foo
BAR

My current idea is that setq applies to variables only, while
setf can apply to other things such as objects. (???)

Again, apologies for the simplicity of the question. I couldn't
figure it out from the Common Lisp spec, or from CLtL2.

glauber

(defclass c ()
  ((x :accessor x)))

(setq i (make-instance 'c))
(setf (x i) 1)

Just one more question in this thread:

is it OK then to use setf to set variables too, or is there any
advantage to using setq? (performance, maybe?)

glauber

SETF applies to "generalized places".  For instance, a location within
an array (as by the accessor AREF) is a place, so to set it, you use:
    (SETF (AREF array index1 ...) newvalue)

Cf. section 5.1 "Generalized Reference" in the HyperSpec
(http://www.xanalys.com/software_tools/reference/HyperSpec/Body/sec_5-...),
as well as the glossary entries for "generalized reference"
(http://www.xanalys.com/software_tools/reference/HyperSpec/Body/glo_g....)
and "place"
(http://www.xanalys.com/software_tools/reference/HyperSpec/Body/glo_p....)

For symbols, it just so happens that

    (SETF FOO 1)

and

    (SETF (SYMBOL-VALUE 'FOO) 1)

are the same thing, largely because

    FOO

and

    (SYMBOL-VALUE 'FOO)

are the same thing.

(SET (QUOTE FOO) 1) and (SETQ FOO 1) are the same thing; SETQ expands
into the SET function, and SET changes the SYMBOL-VALUE of the symbol.

You should probably also take a look at the examples in function
documentation for SET
(http://www.xanalys.com/software_tools/reference/HyperSpec/Body/fun_se...),
as well as read the macro documentation for SETF
(http://www.xanalys.com/software_tools/reference/HyperSpec/Body/mac_se...).

Hope this helps!

 (let ((x 42))
   (symbol-value 'x))

and see whether you get 42 or an "unbound variable" error.  [And if
you do get 42, try again in a real Lisp, instead of in Emacs...]

If you want to develop datastructures, you usually need
a way to change parts of the datastructure and
a way to retrieve parts of the datastructure.
So you need a "getter" and a "setter".
Common Lisp tries to unify this view so that
you need only to know the getter - if the getter
forms a so called place, then you can use SETF
to change the content.

Example:

Array
- getter is AREF
  (aref *an-array* index)
- setting is done via SETF
  (setf (aref *an-array* index) new-value)

Objects
- getter for slots is SLOT-VALUE
  (slot-value object 'slot-name)
- setting is done via SETF
  (setf (slot-value object 'slot-name) new-value)

You can also define new SETF methods.

See http://www.xanalys.com/software_tools/reference/HyperSpec/Body/mac_se...

- use the most specific Lisp facility, this makes
  your intentions clear -> SETQ

- use general mechanisms, this reduces cognitive load, since
  you have to remember less programming constructs  -> SETF

As the other poster said, it's purely a stylistic choice.

 (let ((x 42))
   (symbol-value 'x))

and see whether you get 42 or an "unbound variable" error.  [And if
you do get 42, try again in a real Lisp, instead of in Emacs...]

  setq is a special operator that takes a variable (binding, really)
  and a value, and causes references to that variable (binding) after
  the setq to yield the value.

  setf is a macro that takes a place (generalized reference) and a
  value, and causes references to the place after the setf to yield
  the value, in ways appropriate for each place.  It expands into setq
  for variables (bindings), for instance.

  This is just plain false.

| (SET (QUOTE FOO) 1) and (SETQ FOO 1) are the same thing; SETQ expands
| into the SET function, and SET changes the SYMBOL-VALUE of the symbol.

  This is just plain false, too.

    Paul>  (let ((x 42)) (symbol-value 'x))

Yup.  In my zeal to answer I totally forgot about lexical bindings.

  I think this was a bad idea.  I completely fail to appreciate some
  of the deprecations -- most of them give me this icky Scheme feeling.

  (remove-if-not <obvious-function> ...) is supposed to be inferior to
  (remove-if (complement <obvious-function) ...)?  I'm _so_ thrilled
  with the double negative, already, I really need _complement_!  And
  (set <symbol> <value> is inferior to (setf (symbol-value ...) ...)?
  Gimme a break!

  Deprecation is a signal to the community that it needs to evaluate
  its habits and signal the committee back if it deems them valid.
  For instance, there's no doubt that :test and :test-not had fuzzy
  semantics when combined and non-trivial prophylaxis, but that
  doesn't mean the *-if-not functions suffer similarly fuzziness.

  I use set when I actually have symbols that I don't _want_ to be
  some general data structure.  Symbols are special animals in many
  ways, and I don't want to bury that in a "call" to symbol-value.

For example, if *x* is a global variable then the forms

        (setq *x* t)

and

        (setf *x* t)

compile to different code in ACL 5.0.1 (this is because the SETF macro
inserts a temporary variable in the second case and does not propagate
the T forward in a way that lets the compiler figure out that no write
barrier is needed.)

  If practice differs from theory, you have found a bug.  Report bugs
  as bugs to be removed, not as some nasty thing programmers need to
  be made _aware_ of.  Sheesh!  Such is the worst of all possible ways
  to deal with problems.  If you don't get a fix within a reasonable
  amount of time and the bug causes you to have to circumvent good
  engineering decisions and write bad code that increases the overall
  complexity of the system and introduces portability and maintenance
  issues that are otherwise unwarranted, complain _vociferously_.
  Accept no substitute for fixes to demonstrable bugs!

  (Well, in this here day and age, one _acceptable_ "substitute" for
  fixes to other people's mistakes is a reduced purchase price of the
  buggy product, such as you getting the source code and assuming full
  responsibilit for any problems.  To some of us, that is unworkable.)

| For example, if *x* is a global variable then the forms (setq *x* t)
| and (setf *x* t) compile to different code in ACL 5.0.1 ...

  I have been unable to reproduce this as stated.

I think the feeling was that this isn't such a common thing that we really
need two ways to do it in the language.  30 years ago SETF and DEFSTRUCT
didn't exist, and SET was pretty commonly used, but it's now a relic and
not deserving of such a privileged status.

On the other hand, we didn't deprecate SETQ in favor of SETF because SETQ
is used pervasively.  Making everyone globally replace all their SETQ's
with SETF's would be horrible.

Erik> * Philip Lijnzaad <lijnz...@ebi.ac.uk>
Erik> | But SET has been officially deprecated ...

Erik>   I think this was a bad idea.  I completely fail to appreciate some
Erik>   of the deprecations -- most of them give me this icky Scheme feeling.

I have no real experience with this, but would find

   (setf (symbol-value sym) val)

much much clearer than

   (set sym val)

The first form signals to me that something not entirely usual is going on;
the latter looks more like a nasty-to-spot typo. Like it's kinda clearer to
see

    (funcall (hi-order-func args) more-args)

than

    ((hi-order-func args) more-args)

, really.

Erik>   Gimme a break!

i use SETQ on the principle that using the most specific construct
best communicates intent.

then again, i use (SETF (CAR ...) ...) and (SETF (CDR ...) ...)
rather than RPLACA and RPLACB, so take my advice with a grain of
salt!

so, (SETF (SYMBOL-VALUE ...) ...) is probably expanded in
the following way in all implementations:
     ? (macroexpand '(setf (symbol-value '*a*) 5))
     (SET '*A* 5)
      T
     ?
does this imply that SET will never disappear, then, for
if it did, SETF would have no ANSI CL construct to expand to
(i.e., one that modifies dynamic bindings)?

the same logic seems to imply that, the pervasiveness of
SETQ aside, it will never go away because (SETF <symbol> ...)
will always require it for expansion purposes.

is this right?  one way that i could be wrong is that it
could be perfectly legal for SETF to macroexpand into
implementation-specific mechanisms for modifying bindings,
but this just seems wrong.

(funcall #'(setf set) 5 '*A*)

or

(SYSTEM-INTERNAL::SET-SYMBOL-VALUE '*A* 5)

  Why do you assume that?  Why should it be mandated?

| one way that i could be wrong is that it could be perfectly legal
| for SETF to macroexpand into implementation-specific mechanisms for
| modifying bindings, but this just seems wrong.

  Could you elaborate on why you think this way?

BUT any such implementation-specific mechanism _must_ be (or eventually
macroexpand into) a call to an implementation function.  No implementation
setf expansion, nor for that matter any other standard macro, may expand
into a nonstandard special form.  To do so would make it impossible for
portable code walkers to work, and that would be a bad thing.