* Purpose of dash # in elisp
@ 2009-11-08 20:01 Nordlöw
2009-11-08 21:29 ` Pascal J. Bourguignon
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Nordlöw @ 2009-11-08 20:01 UTC (permalink / raw)
To: help-gnu-emacs
What purpose does # as a quote suffix?
/Nordlöw
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Purpose of dash # in elisp
2009-11-08 20:01 Purpose of dash # in elisp Nordlöw
@ 2009-11-08 21:29 ` Pascal J. Bourguignon
2009-11-09 10:53 ` Tassilo Horn
[not found] ` <mailman.10334.1257764064.2239.help-gnu-emacs@gnu.org>
2 siblings, 0 replies; 5+ messages in thread
From: Pascal J. Bourguignon @ 2009-11-08 21:29 UTC (permalink / raw)
To: help-gnu-emacs
Nordlöw <per.nordlow@gmail.com> writes:
> What purpose does # as a quote suffix?
What's the relationship between this question and the one asked in the
Subject: apart from the # character?
Lisp texts are read from left to right. When a quote appears, it is
read alone. Then another object is read (an object is built depending
on the characters read), and the list (quote <the-object-read>) is
returned.
There's no such notion of quote suffix.
Then, when you read # character other characters are read to determine
what must be read. First, if digits appears they are interpreted as
an integer in base ten, and are used as an argument to the "reader
macro" (there's no "reader macro" per se in emacs lisp, although its
reader implements most of the standard reader macros of Common Lisp).
The first non digit character following the # determines what must be
read.
Subchar What is read What is returned
= one expression that expression this expression is remembered
under the numerical index given.
# nothing the expression that
was remembered under
the given numerical
index.
' one expression the list (function that-expression)
: the name of a new uninterned symbol with that name
a symbol
( a list a string with properties (the characters
come from the first item of the list
which must be a string, the properties
follow).
etc etc etc You should read the emacs lisp manual.
other nothing nothing an invalid syntax error is signaled.
--
__Pascal Bourguignon__
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Purpose of dash # in elisp
2009-11-08 20:01 Purpose of dash # in elisp Nordlöw
2009-11-08 21:29 ` Pascal J. Bourguignon
@ 2009-11-09 10:53 ` Tassilo Horn
[not found] ` <mailman.10334.1257764064.2239.help-gnu-emacs@gnu.org>
2 siblings, 0 replies; 5+ messages in thread
From: Tassilo Horn @ 2009-11-09 10:53 UTC (permalink / raw)
To: help-gnu-emacs
Nordlöw <per.nordlow@gmail.com> writes:
> What purpose does # as a quote suffix?
You mean as prefix, e.g.
(mapcar #'oddp '(1 2 3))
versus
(mapcar 'oddp '(1 2 3))?
Both forms are completely equivalent (try disassembling them), but the
former is more common to a common lisp programmer, where you pass
function symbols with the `function' macro and its reader form #', and
other symbols that should not be evaled with `quote' (which is ').
If you stick to the convention to always use #' when passing a function
as arguments, the code might be a littlebit more explanatory, because
then you can see that a function is passed on a first glance. On the
other hand, in elisp the reader won't error or warn if you use #' to
pass anything different, so this convention wouldn't be enforced
somehow.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Purpose of dash # in elisp
[not found] ` <mailman.10334.1257764064.2239.help-gnu-emacs@gnu.org>
@ 2009-11-09 13:00 ` Pascal J. Bourguignon
2009-11-09 17:27 ` Lennart Borgman
0 siblings, 1 reply; 5+ messages in thread
From: Pascal J. Bourguignon @ 2009-11-09 13:00 UTC (permalink / raw)
To: help-gnu-emacs
Tassilo Horn <tassilo@member.fsf.org> writes:
> Nordlöw <per.nordlow@gmail.com> writes:
>
>> What purpose does # as a quote suffix?
>
> You mean as prefix, e.g.
>
> (mapcar #'oddp '(1 2 3))
>
> versus
>
> (mapcar 'oddp '(1 2 3))?
>
> Both forms are completely equivalent (try disassembling them), but the
> former is more common to a common lisp programmer, where you pass
> function symbols with the `function' macro and its reader form #', and
> other symbols that should not be evaled with `quote' (which is ').
>
> If you stick to the convention to always use #' when passing a function
> as arguments, the code might be a littlebit more explanatory, because
> then you can see that a function is passed on a first glance. On the
> other hand, in elisp the reader won't error or warn if you use #' to
> pass anything different, so this convention wouldn't be enforced
> somehow.
(first ' #'x) --> function
(first ' 'x) --> quote
It happens that in emacs lisp, function and quote evaluate the same:
they both return their unevaluated argument unchanged.
However, when compiling, they don't behave the same. function means
that the argument is CODE, while quote says that the argument is DATA.
(disassemble (byte-compile (lambda () '(lambda (x) (+ x x)))))
produces:
byte code:
args: nil
0 constant (lambda (x) (+ x x))
1 return
(disassemble (byte-compile (lambda () #'(lambda (x) (+ x x)))))
produces:
byte code:
args: nil
0 constant <compiled-function>
args: (x)
0 varref x
1 dup
2 plus
3 return
1 return
When the lambda form is quoted, it is considered data, and the
compiler doesn't compile it, but when it's function'ed, it is
considered code, and it is compiled too.
Notice that lambda itself is a macro that expands to a function form:
(macroexpand '(lambda (x) (+ x x)))
--> (function (lambda (x) (+ x x)))
Nonetheless some programmers (not me) like to prefix lambda forms with #':
(mapcar #'(lambda (x) (+ x x)) '(1 2 3))
I just write:
(mapcar (lambda (x) (+ x x)) '(1 2 3))
which compiles to the same. On the other hand, compiling:
(mapcar '(lambda (x) (+ x x)) '(1 2 3))
wouldn't compile the lambda form, and therefore would produce slower
code in general.
In the case of function names, 'fun or #'fun will indeed produce the
same results in all cases, in emacs lisp (in Common Lisp they would
produce different results in some situations).
emacs lisp:
'sin --> sin
#'sin --> sin
Common Lisp:
'sin --> SIN
#'sin --> #<SYSTEM-FUNCTION SIN>
--
__Pascal Bourguignon__
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Purpose of dash # in elisp
2009-11-09 13:00 ` Pascal J. Bourguignon
@ 2009-11-09 17:27 ` Lennart Borgman
0 siblings, 0 replies; 5+ messages in thread
From: Lennart Borgman @ 2009-11-09 17:27 UTC (permalink / raw)
To: Pascal J. Bourguignon; +Cc: help-gnu-emacs
On Mon, Nov 9, 2009 at 2:00 PM, Pascal J. Bourguignon
<pjb@informatimago.com> wrote:
>
> (first ' #'x) --> function
> (first ' 'x) --> quote
>
> It happens that in emacs lisp, function and quote evaluate the same:
> they both return their unevaluated argument unchanged.
>
> However, when compiling, they don't behave the same. function means
> that the argument is CODE, while quote says that the argument is DATA.
>
> (disassemble (byte-compile (lambda () '(lambda (x) (+ x x)))))
> produces:
>
> byte code:
> args: nil
> 0 constant (lambda (x) (+ x x))
> 1 return
>
>
>
> (disassemble (byte-compile (lambda () #'(lambda (x) (+ x x)))))
> produces:
>
> byte code:
> args: nil
> 0 constant <compiled-function>
> args: (x)
> 0 varref x
> 1 dup
> 2 plus
> 3 return
>
> 1 return
>
>
> When the lambda form is quoted, it is considered data, and the
> compiler doesn't compile it, but when it's function'ed, it is
> considered code, and it is compiled too.
Is this a bug, or?
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-11-09 17:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-08 20:01 Purpose of dash # in elisp Nordlöw
2009-11-08 21:29 ` Pascal J. Bourguignon
2009-11-09 10:53 ` Tassilo Horn
[not found] ` <mailman.10334.1257764064.2239.help-gnu-emacs@gnu.org>
2009-11-09 13:00 ` Pascal J. Bourguignon
2009-11-09 17:27 ` Lennart Borgman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).