Re: Whats wrong with this defcustom?

[Robert Thorpe <rt@robertthorpeconsulting.com>]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
...
>
> Ok, precision matters, so a quoted symbol is at the same time an
> unquoted *expression* that returns the symbol itself ... while an unquoted symbol
> in an unquoted *expression* that tries to return the symbols value (as a
> variable) ... (?)


Apologies if I explain things you already know.  See below:
*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (setq bar 4)
4
ELISP> (setq foo bar)
4
ELISP> foo
4
ELISP> bar
4
ELISP> (setq foo 'bar)
bar
ELISP> foo
bar
ELISP> bar
4

Think about setq....  If you want to set foo to the symbol bar then you
have to quote it.  Similarly, in defcustom if you want the STANDARD to
be a symbol then you have to quote it, so quoting "notes" is right.  On
the other hand the whole "'choice ..." expression is quoted.  It's a
data structure, a little list/tree made up of strings and symbols.  The
bit in the docstring is telling you not to quote anything except
symbols.

This may help...  Last week I replied to a question about symbols and
explained what they are.  Sometimes the lisp interpreter evaluates and
sometimes it doesn't, that confuses things.  I wrote: "If we have a
function call: (foo bar 'baz) then lisp treats each of these symbols
differently.  It finds the function slot for foo because that's the
first symbol, it finds the variable slot for bar because it's not first.
Finally, 'baz returns the symbol itself.  To be more careful: (quote
baz) returns a list containing the symbol, which evaluates to the
symbol".  That applies to functions, other things can be different.

Imagine we have a lisp interpreter that works on lisp lists.  It takes a
tree (a lisp list) and evaluates it (the "eval" function) by looking at
the first argument and figuring out what to do.  Some "special forms"
are dealt with directly.  For other things the interpreter finds the
corresponding function.  If you think about this it needs to decide how
to deal with arguments.  They can be "unevalled", the relevant fragment
of the list can be used as-is.  Or it can be "evalled" in which case a
recursive call to the eval function is needed.  In that case a list
would be interpreted as a function call and a sole symbol as a variable
reference.  Does the lisp programmer need to deal with both unevalled
and evalled type arguments?  Not really, a special-form can be provided
to switch between the two.  The special-form "Quote" takes its arguments
unevalled and simply returns them; '(something) is just an abbreviation
for (quote something).

As well as quote, there are a few built-in special forms that work that
way.  There are also macros which operate directly on lists.  They get
lists from the reader before evaluation begins, then they transform
them.

For example, "eval-when-compile" is a macro.  It takes an argument BODY
which is unquoted.  On the other hand, "eval-after-load" is a function
it takes two arguments FILE and FORM.  Since it's a function FORM must
be quoted.  Because eval-after-load is a function it must call eval
explicitly to deal with FORM.  The line in defcustom's documentation
about not quoting is there to say that defcustom behaves like
"eval-when-compile" not like "eval-after-load".

BR,
Robert Thorpe