all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Pascal J. Bourguignon" <pjb@informatimago.com>
To: help-gnu-emacs@gnu.org
Subject: Re: how to add button to emacs that play a elisp code
Date: Sat, 13 Sep 2014 23:28:44 +0200	[thread overview]
Message-ID: <878ulnmcqb.fsf@kuiper.lan.informatimago.com> (raw)
In-Reply-To: 87d2b1vh2w.fsf@debian.uxu

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


  parent reply	other threads:[~2014-09-13 21:28 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-11  7:44 how to add button to emacs that play a elisp code Renato Pontefice
2014-09-11  8:08 ` Gian Uberto Lauri
2014-09-11  8:40   ` Gian Uberto Lauri
2014-09-11 12:17     ` Stefan Monnier
2014-09-11 12:22       ` Gian Uberto Lauri
2014-09-11 12:35         ` Stefan Monnier
2014-09-11 12:46           ` Gian Uberto Lauri
     [not found]         ` <mailman.8685.1410439222.1147.help-gnu-emacs@gnu.org>
2014-09-11 21:15           ` Emanuel Berg
2014-09-11 23:42             ` Pascal J. Bourguignon
2014-09-12  0:05               ` Emanuel Berg
2014-09-12  0:23                 ` Michael Heerdegen
     [not found]                 ` <mailman.8717.1410481417.1147.help-gnu-emacs@gnu.org>
2014-09-12  0:50                   ` Emanuel Berg
2014-09-12  1:19                     ` Michael Heerdegen
2014-09-12 14:52                       ` Drew Adams
     [not found]                     ` <mailman.8719.1410484774.1147.help-gnu-emacs@gnu.org>
2014-09-12  2:07                       ` Emanuel Berg
2014-09-12  7:44                         ` Renato Pontefice
2014-09-12 10:15                           ` Renato Pontefice
2014-09-12 19:33                             ` Emanuel Berg
2014-09-13 21:28                 ` Pascal J. Bourguignon [this message]
2014-09-14  2:30                   ` Rusi
2014-09-14  4:18                     ` Rusi
2014-09-14 18:16                     ` Emanuel Berg
2014-09-14 18:11                   ` Emanuel Berg
2014-09-15  5:48                     ` Alex Kost
     [not found]                     ` <mailman.8874.1410760111.1147.help-gnu-emacs@gnu.org>
2014-09-15 22:45                       ` Emanuel Berg
2014-09-16  4:55                         ` Alex Kost
     [not found]                         ` <mailman.8956.1410843332.1147.help-gnu-emacs@gnu.org>
2014-09-16 22:27                           ` Emanuel Berg
     [not found]   ` <mailman.8671.1410424828.1147.help-gnu-emacs@gnu.org>
2014-09-11 21:06     ` Emanuel Berg
     [not found] ` <mailman.8670.1410422963.1147.help-gnu-emacs@gnu.org>
2014-09-11  8:24   ` Renato Pontefice
2014-09-11 16:00 ` Pascal J. Bourguignon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878ulnmcqb.fsf@kuiper.lan.informatimago.com \
    --to=pjb@informatimago.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.