12

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?

  • . is not a function. . is not a variable. Nothing happened -- zip, zero, zilch, nada. – lawlist Nov 4 '16 at 7:33
  • @lawlist It seems to be a bit more complicated than that. E.g. qsdf is not a function either, but (qsdf 123) yields void function.... And (. 123 456) yields a syntax error ". in wrong context". – T. Verron Nov 4 '16 at 7:38
  • 1
    Looks like an edge case in the reader to me... – wasamasa Nov 4 '16 at 7:39
  • 1
    Btw, the equivalent of bash's . (or source) in elisp is probably load. – T. Verron Nov 4 '16 at 7:41
  • (. 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! – Tobias Nov 4 '16 at 7:56
15

It 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...

| improve this answer | |
  • Isn't Guile GNU as well? – T. Verron Nov 4 '16 at 9:49
  • Yes, but so is MIT-Scheme these days. – wasamasa Nov 4 '16 at 14:40
  • 3
    Please consider reporting an Emacs bug. This is not "normal" Lisp behavior. What's more, it seems to be undocumented behavior. – Drew Nov 4 '16 at 14:58
  • I reported this in bug#24875. – xuchunyang Nov 5 '16 at 3:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.