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

[Rusi <rustompmody@gmail.com>]

On Sunday, September 14, 2014 2:58:44 AM UTC+5:30, Pascal J. Bourguignon wrote:
> Emanuel Berg writes:

> > "Pascal J. Bourguignon" 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!

Ive always found that talking about the semantics of lisp (as compared
to more modern functional languages) is quite tricky because of quote.

Here is Wadler spelling out the problem
http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf

I often get into arguments on the python list because I find python's
'is' operator (roughly lisp's 'eq) a terrible name in that it
insidiously coincides identity in the philosophical sense with pointer
identity.

Here http://blog.languager.org/2013/08/applying-si-on-sicp.html
is my own take on this and why even the inventors of scheme seem to 
have missed some key points in scheme (lisp) philosophy.