help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to add button to emacs that play a elisp code


From: Pascal J. Bourguignon
Subject: Re: how to add button to emacs that play a elisp code
Date: Sat, 13 Sep 2014 23:28:44 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

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

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>
>> list always return a new list or nil. quote always
>> return the very same object it has in argument.
>>
>> It's not the same at all!
>
> Of course list is not the same as quote in general.
>
> But those examples are the same in the sense that when
> I evaluate them I get the same result. You can try that
> yourself, here:
>
> '(1 2 3)        ; (1 2 3)
> (quote (1 2 3)) ; same
> (list 1 2 3)    ; same

No. That's the point.  I'm using clhs definition of same(2), since elisp
info doesn't provide a glossary.  

    same adj. 1. (of objects under a specified predicate) indistinguishable
    by that predicate. ``The symbol car, the string "car", and the string
    "CAR" are the same under string-equal''. 2. (of objects if no predicate
    is implied by context) indistinguishable by eql. Note that eq might be
    capable of distinguishing some numbers and characters which eql cannot
    distinguish, but the nature of such, if any, is
    implementation-dependent. Since eq is used only rarely in this
    specification, eql is the default predicate when none is mentioned
    explicitly. ``The conses returned by two successive calls to cons are
    never the same.'' 3. (of types) having the same set of elements; that
    is, each type is a subtype of the others. ``The types specified by
    (integer 0 1), (unsigned-byte 1), and bit are the same.'' 


But notice that the same meaning seems to be used rather consistently in
the elisp info, for example in section "5.6.3 Functions that Rearrange
Lists", the description of sort says:

     Sorting does not change the CARs of the cons cells in LIST; the
     cons cell that originally contained the element `a' in LIST still
     has `a' in its CAR after sorting, but it now appears in a
     different position in the list due to the change of CDRs.  For
     example:

          (setq nums '(1 3 2 6 5 4 0))
               => (1 3 2 6 5 4 0)
          (sort nums '<)
               => (0 1 2 3 4 5 6)
          nums
               => (1 2 3 4 5 6)

     *Warning*: Note that the list in `nums' no longer contains 0; this
     is the same cons cell that it was before, but it is no longer the
     first one in the list.  Don't assume a variable that formerly held
     the argument now holds the entire sorted list!  Instead, save the
     result of `sort' and use that.  Most often we store the result
     back into the variable that held the original list:



>>> By the way, I thought I would make it even more
>>> pedagogical with `functionp' and `listp', but:
>>> (functionp '(lambda () (interactive) 1)) ; t (listp
>>> (lambda () (interactive) 1)) ; t
>>
>> This is wrong also.
>
> "Wrong"? Those are the results I get. Here:
>
> (functionp '(lambda () (interactive) 1)) ; t
> (listp      (lambda () (interactive) 1)) ; t

I've shown you that you get this result by pure chance, just because it
happens that you didn't compile that code!

Read the whole messages and don't truncate them indiscriminately!

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk


reply via email to

[Prev in Thread] Current Thread [Next in Thread]