I learnt . /path/to/file
in bash is used to execute a file. Just out of curiosity, I eval something like the following in Emacs
(. 123)
⇒ 123
(read "(. 123)")
⇒ 123
It looks like Emacs simply reads (. 123)
as 123
, what happened?
Emacs Stack Exchange is a question and answer site for those using, extending or developing Emacs. It only takes a minute to sign up.
Sign up to join this communityIt looks like Emacs simply reads (. 123) as 123, what happened?
That's exactly what happened. To back it up with sources:
if (ch == '.')
{
if (!NILP (tail))
XSETCDR (tail, read0 (readcharfun));
else
val = read0 (readcharfun);
read1 (readcharfun, &ch, 0);
if (ch == ')')
{
if (doc_reference == 1)
return make_number (0);
if (doc_reference == 2 && INTEGERP (XCDR (val)))
/* ... */
return val;
}
invalid_syntax (". in wrong context");
}
This is the special case for read_list
in lread.c
. Normally a .
is treated by setting the cdr of the previously read tail by whatever
follows. However in the case there is no tail (like when reading
(. 123)
), the next thing is read and returned as is. Personally,
I'd expect that to lead to an invalid syntax error, but I'm sure
someone put the special case there to work around peculiarly terrible
sources. I've tried out how other Lisp interpreters behave for fun
and none of csi
, pil
and sbcl
do permit reading this, so it may
be worth a bug report.
edit: Guile behaves the same, MIT-Scheme doesn't. There goes my theory of this behavior being a GNU thing...
.
is not a function..
is not a variable. Nothing happened -- zip, zero, zilch, nada.qsdf
is not a function either, but(qsdf 123)
yieldsvoid function...
. And(. 123 456)
yields a syntax error". in wrong context"
..
(orsource
) in elisp is probablyload
.(. 123)
on tutorialspoint.com/execute_lisp_online.php gives*** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER #P"main.lisp" @1>: token "." not allowed here
. In emacs:(boundp '.)
→nil
and(fboundp '.)
→nil
. I.e., the effect described by you is very strange!