Re: Whats wrong with this defcustom?

Re: Whats wrong with this defcustom?

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> What you quote above is mostly what Thien-Thi Nguyen
> wrote.

Well, yeah, he wrote it, but you quoted it, and the
last line of the quote, you wrote.

> He used (some char) means "equivalent to" or
> "identical to".

Yes, I understood him.

> The lisp reader translates '(foo bar) into (quote
> (foo bar)) which is evaluated. The quote special form
> doesn't evaluate it's argument. So, evaluating it
> produces "(foo bar)". I wrote "returned" because
> quote is rather like a function that's called and
> returns something.

Yeah, in languages such as C you have a function and a
type for the return value and then an explicit return
keyword to denote when it happens, and what is
returned. In Elisp you have types but not typed
functions and everything evaluates to something (but
can have side-effects just the same). I don't know if
there are some subtle differences between returning and
evaluating, except for that evaluating seems more
flexible as it can be done in several ways (for
example, prog1 and progn) but perhaps it can also be
more confusing as it isn't typed or explicit (not as
clear as in C anyway), and also because while
everything evaluates to something, it is far from
always that result is what matters. Tho I prefer Lisp
because of its power and the dynamics to it (evaluating
parts while working with the code, etc.) I actually
think C is easier to read (when I write C and Elisp, I
mean). What I like with Lisp is that you can do almost
everything with it. It is like Bruce Lee. Paradigm
free, the style of no style. Technique doesn't matter
(that much), but delivery (execution) does. It is like
a boxer throwing 200 jabs in a fight. Only 25 lands -
those were all jabs, i.e., identical techniques. What
made some land and some not was factors external to the
techniques themselves. So that is why I don't like
paradigmic discussions any more than outright language
wars, because I don't see that as being the thing that
matters.

> Equality is something else, as you've found.

I have? What I meant, if something evaluates to
something, and something else evaluates to something -
are they the same? - these somethings (before
evaluating) should be put into Lisp functions so we can
see for ourselves. Only then, question is, what
function should be used?

-- 
underground experts united

Re: Whats wrong with this defcustom?

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> ... I actually think C is easier to read (when I write C
> and Elisp, I mean).

Here is one example. This is a pretty straightforward
implementation of an interface that shows open
man pages according to the cache principle, only when
you start typing (any other char than those presented
as options), you get an ordinary type interface
seamlessly. Still, the code gets immensely complicated
and if any other person other than yours truly wrote
that, I wouldn't understand one word. C isn't like that
in my mind.

screenshot: http://user.it.uu.se/~embe8573/dumps/man.png

source: http://user.it.uu.se/~embe8573/conf/emacs-init/man-my.el

-- 
underground experts united

Re: Whats wrong with this defcustom?

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:
...
>> Equality is something else, as you've found.
>
> I have?

What I mean is, Emacs Lisp has several types of equality, eq, equal,
etc.  Thien-Thi Nguyen corrected my mistake about lisp reader syntax.
That is, "'(something)" turns into "(quote (something))".  This is a
conversion that happens before evaluation is involved and before
equality is involved (as you may know).  Then later evaluation turns it
into "(something)".

The lisp reader is very separate from the lisp interpreter or compiler, for
example think about this:
(let* ((x 1257) #'x) function)

BR,
Robert Thorpe

Re: Whats wrong with this defcustom?

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> What I mean is, Emacs Lisp has several types of
> equality, eq, equal, etc. Thien-Thi Nguyen corrected
> my mistake about lisp reader syntax. That is,
> "'(something)" turns into "(quote (something))".

Yes.

> This is a conversion that happens before evaluation
> is involved and before equality is involved (as you
> may know). Then later evaluation turns it into
> "(something)".

Yeah? Isn't it just plain evaluation inside-out?

(equal '(something) (quote (something)))     ; t
(equal '(something) (quote (somethingelse))) ; nil

> The lisp reader is very separate from the lisp
> interpreter or compiler, for example think about
> this: (let* ((x 1257) #'x) function)

OK? What does that illustrate?

Is there a hidden layer somewhere?

Equality in terms of data, isn't that just comparing
the end results of evaluation? (And this equality being
defined differently for the different functions.)

Equality in terms of code - can that be anything short
of identical code (perhaps not taking indentation and
such into account)?

-- 
underground experts united

Re: Whats wrong with this defcustom?

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
...
> Yeah? Isn't it just plain evaluation inside-out?
>
> (equal '(something) (quote (something)))     ; t
> '(equal '(something) (quote (somethingelse))) ; nil

My point is only that the '(something) is converted into (quote
(something)) by the lisp reader.  Equality wasn't really the issue
because that conversion happens before the lisp interpreter proper gets
involved.  It happens before the interpreters ideas about equality are involved.

What the interpreter or evaluator sees for the code above is:
(equal (quote (something)) (quote (something))) ; t
(equal (quote (something)) (quote (somethingelse))) ; nil

BR,
Robert Thorpe

Re: Whats wrong with this defcustom?

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

>> () Robert Thorpe <rt@robertthorpeconsulting.com> ()
>> Tue, 29 Jul 2014 01:46:10 +0100 '(something) is just
>> an abbreviation for (quote something). This is not
>> correct. '(something) ≡ (quote (something)) which
>> evals to a list of one element, the symbol
>> ‘something’ i.e., => (something)
>
> I agree, you're right.

I think you meant 'something is equal to (quote
something)? Because it is, right?

These seem to be equal though the third perhaps doesn't
make any sense in this example:

(list 1 2 3)
'(1 2 3)
`(1 2 3)

By the way I cannot find a &rest equality function in
Elisp - perhaps there isn't any?

That also brings about, when we say things are equal,
by what function do we mean? There are so many of them
you get dizzy:

(= 1 1)
(= 1 1.0)
(eq 1   1)
(eq 1   1.0)  ; nil
(eq 1.0 1.0)  ; nil (?)
(eql 1.0 1.0) ; t
(eql 1   1.0) ; nil
(equal '(1 2 3) '(1 2 3))
(equal "read this" (propertize "read this" :bold t)) ; t
(equal-including-properties "read this" (propertize "read this" :bold t)) ; nil

-- 
underground experts united

Re: Whats wrong with this defcustom?

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>>> () Robert Thorpe <rt@robertthorpeconsulting.com> ()
>>> Tue, 29 Jul 2014 01:46:10 +0100 '(something) is just
>>> an abbreviation for (quote something). This is not
>>> correct. '(something) ≡ (quote (something)) which
>>> evals to a list of one element, the symbol
>>> ‘something’ i.e., => (something)
>>
>> I agree, you're right.
>
> I think you meant 'something is equal to (quote
> something)? Because it is, right?

What you quote above is mostly what Thien-Thi Nguyen wrote.  He used ≡
which means "equivalent to" or "identical to".

The lisp reader translates '(foo bar) into (quote (foo bar)) which is
evaluated.  The quote special form doesn't evaluate it's argument.  So,
evaluating it produces "(foo bar)".  I wrote "returned" because quote is
rather like a function that's called and returns something.  (And in an
interpreter that's a recursive evaluator it may be done by a function
return.)

Equality is something else, as you've found.

BR,
Robert Thorpe

Re: Whats wrong with this defcustom?

[Olve]

Le 26/07/2014 12:55, Thorsten Jolitz a écrit :
 > (defcustom org-x-style 'notes
 > |   "Possible styles for diagrams."
 > |   :group 'org-x
 > |   :type '(choice (const :tag "Sync-bars" 'sync-bars)
 > |          (const :tag "Partitions" 'partitions)
 > |          (const :tag "Notes" 'notes)))

(defcustom org-x-style 'notes
    "Possible styles for diagrams."
    :group 'org-x
    :type '(choice (const :tag "Sync-bars" sync-bars)
           (const :tag "Partitions" partitions)
           (const :tag "Notes" notes)))

The last symbols in const should not be quoted (or double-quote the 
initial value !) A.O.

Re: Whats wrong with this defcustom?

[Thorsten Jolitz]

Olve <Olve@nowhere.invalid> writes:

> Le 26/07/2014 12:55, Thorsten Jolitz a écrit :
>> (defcustom org-x-style 'notes
>> |   "Possible styles for diagrams."
>> |   :group 'org-x
>> |   :type '(choice (const :tag "Sync-bars" 'sync-bars)
>> |          (const :tag "Partitions" 'partitions)
>> |          (const :tag "Notes" 'notes)))
>
> (defcustom org-x-style 'notes
>    "Possible styles for diagrams."
>    :group 'org-x
>    :type '(choice (const :tag "Sync-bars" sync-bars)
>           (const :tag "Partitions" partitions)
>           (const :tag "Notes" notes)))
>
> The last symbols in const should not be quoted (or double-quote the
> initial value !) A.O.

Ah, ok, that works. Thanks! I knew it must be a small issue, but not
which one ...

-- 
cheers,
Thorsten

Whats wrong with this defcustom?

[Thorsten Jolitz]

Hi List, 

I'm probably overlooking the obvious, but what is wrong with this
defcustom:

,----
| (defcustom org-x-style 'notes
|   "Possible styles for diagrams."
|   :group 'org-x
|   :type '(choice (const :tag "Sync-bars" 'sync-bars)
| 		 (const :tag "Partitions" 'partitions)
| 		 (const :tag "Notes" 'notes)))
`----

why do I get the (mismatch) note but no choices?

,----
| Hide org-x-style: 'notes
|    [ State ]: STANDARD. (mismatch)
|    Possible styles for diagrams.
| Groups: [Org X]
`----

Thanks in advance for any hint.

-- 
cheers,
Thorsten

Re: Whats wrong with this defcustom?

[Tassilo Horn]

Thorsten Jolitz <tjolitz@gmail.com> writes:

Hi Thorsten,

> I'm probably overlooking the obvious, but what is wrong with this
> defcustom:
>
> ,----
> | (defcustom org-x-style 'notes
> |   "Possible styles for diagrams."
> |   :group 'org-x
> |   :type '(choice (const :tag "Sync-bars" 'sync-bars)
> | 		 (const :tag "Partitions" 'partitions)
> | 		 (const :tag "Notes" 'notes)))
> `----

,----[ C-h f defcustom RET ]
| defcustom is a Lisp macro in `custom.el'.
| 
| (defcustom SYMBOL STANDARD DOC &rest ARGS)
| 
| Declare SYMBOL as a customizable variable.
| SYMBOL is the variable name; it should not be quoted.
| STANDARD is an expression specifying the variable's standard
| value.  It should not be quoted.
|         ^^^^^^^^^^^^^^^^^^^^^^^
`----

Bye,
Tassilo

Re: Whats wrong with this defcustom?

[Thorsten Jolitz]

Tassilo Horn <tsdh@gnu.org> writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:

Hi Tassilo,

>> I'm probably overlooking the obvious, but what is wrong with this
>> defcustom:
>>
>> ,----
>> | (defcustom org-x-style 'notes
>> |   "Possible styles for diagrams."
>> |   :group 'org-x
>> |   :type '(choice (const :tag "Sync-bars" 'sync-bars)
>> | 		 (const :tag "Partitions" 'partitions)
>> | 		 (const :tag "Notes" 'notes)))
>> `----
>
> ,----[ C-h f defcustom RET ]
> | defcustom is a Lisp macro in `custom.el'.
> | 
> | (defcustom SYMBOL STANDARD DOC &rest ARGS)
> | 
> | Declare SYMBOL as a customizable variable.
> | SYMBOL is the variable name; it should not be quoted.
> | STANDARD is an expression specifying the variable's standard
> | value.  It should not be quoted.
> |         ^^^^^^^^^^^^^^^^^^^^^^^
> `----

Right, I fixed this too ... thx.
Quoting symbols is done so often that unquoted symbols somehow look
wrong (when unaware of dealing with a macro ...)

-- 
cheers,
Thorsten

Re: Whats wrong with this defcustom?

[Stefan Monnier]

> | STANDARD is an expression specifying the variable's standard
> | value.  It should not be quoted.
> |         ^^^^^^^^^^^^^^^^^^^^^^^

The underscored text means that you shouldn't write

   '(concat foo bar)
but
   (concat foo bar)

I.e. his 'notes is perfectly correct: it's an unquoted *expression*
which will return the symbol `notes' when evaluated.


        Stefan

Re: Whats wrong with this defcustom?

[Thorsten Jolitz]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> | STANDARD is an expression specifying the variable's standard
>> | value.  It should not be quoted.
>> |         ^^^^^^^^^^^^^^^^^^^^^^^
>
> The underscored text means that you shouldn't write
>
>    '(concat foo bar)
> but
>    (concat foo bar)
>
> I.e. his 'notes is perfectly correct: it's an unquoted *expression*
> which will return the symbol `notes' when evaluated.

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) ... (?)

-- 
cheers,
Thorsten

Re: Whats wrong with this defcustom?

[Robert Thorpe]

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

Re: Whats wrong with this defcustom?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

() Robert Thorpe <rt@robertthorpeconsulting.com>
() Tue, 29 Jul 2014 01:46:10 +0100

   '(something) is just an abbreviation for
   (quote something).

This is not correct.

 '(something) ≡ (quote (something))
 which evals to a list of one element, the symbol ‘something’
 i.e., => (something)

but

 (quote something) ≡ 'something
 which evals to the symbol ‘something’
 i.e., => something

Also, i think it's better to say "evals to" rather than "returns".
The latter strikes me as indicative of a function-call context.
OTOH, ‘eval’ is a function, so i suppose YMMV...  :-D

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Whats wrong with this defcustom?

[Robert Thorpe]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> () Robert Thorpe <rt@robertthorpeconsulting.com>
> () Tue, 29 Jul 2014 01:46:10 +0100
>
>    '(something) is just an abbreviation for
>    (quote something).
>
> This is not correct.
>
>  '(something) ≡ (quote (something))
>  which evals to a list of one element, the symbol ‘something’
>  i.e., => (something)

I agree, you're right.

BR,
Robert Thorpe

Re: Whats wrong with this defcustom?

[Thorsten Jolitz]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> 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.

Well, I did quote the STANDARD argument in my defcustom correctly and
really actually know that in an already quoted list I should not quote
symbols again, but that did not prevent me from doing it wrong and then
being unable to see my mistake ;)

Since 'foo is (quote foo) which is an unquoted expression the docstring
of `defcustom` is correct, and I did not think it through before doing
my bug-report, shame on me. 

Thanks for your long and interesting explanations anyway!

-- 
cheers,
Thorsten

Re: Whats wrong with this defcustom?

[Sebastian Wiesner]

Am 26.07.2014 um 12:55 schrieb Thorsten Jolitz <tjolitz@gmail.com>:

> 
> Hi List, 
> 
> I'm probably overlooking the obvious, but what is wrong with this
> defcustom:
> 
> ,----
> | (defcustom org-x-style 'notes
> |   "Possible styles for diagrams."
> |   :group 'org-x
> |   :type '(choice (const :tag "Sync-bars" 'sync-bars)
> | 		 (const :tag "Partitions" 'partitions)
> | 		 (const :tag "Notes" 'notes)))
> `——

Remove the quotes from the symbols inside the `(const …)` expressions.  The outer `choice` is already quoted, so you are “double-quoting” the choices.  Hence the mismatch: The symbol "notes" is different from the expression "(quote notes)".

Re: Whats wrong with this defcustom?

[Thorsten Jolitz]

Sebastian Wiesner <swiesner@lunaryorn.com> writes:

> Am 26.07.2014 um 12:55 schrieb Thorsten Jolitz <tjolitz@gmail.com>:
>
>> 
>> Hi List, 
>> 
>> I'm probably overlooking the obvious, but what is wrong with this
>> defcustom:
>> 
>> ,----
>> | (defcustom org-x-style 'notes
>> |   "Possible styles for diagrams."
>> |   :group 'org-x
>> |   :type '(choice (const :tag "Sync-bars" 'sync-bars)
>> | 		 (const :tag "Partitions" 'partitions)
>> | 		 (const :tag "Notes" 'notes)))
>> `——
>
> Remove the quotes from the symbols inside the `(const …)` expressions.
> The outer `choice` is already quoted, so you are “double-quoting” the
> choices.  Hence the mismatch: The symbol "notes" is different from the
> expression "(quote notes)".

Yes, thanks, I see it now but somehow did not see it before, there were
4 redundant quotes in that def, STANDARD and those inside the '(const
...)' expressions, I fixed that now.

,----[ C-h f defcustom RET ]
| defcustom is a Lisp macro in `custom.el'.
| 
| (defcustom SYMBOL STANDARD DOC &rest ARGS)
| 
| Declare SYMBOL as a customizable variable.
| SYMBOL is the variable name; it should not be quoted.
| STANDARD is an expression specifying the variable's standard
| value.  It should not be quoted.
`----

-- 
cheers,
Thorsten