Significado del punto en (. 123)

Aprendí que . /path/to/fileen bash se usa para ejecutar un archivo. Solo por curiosidad, evalúo algo como lo siguiente en Emacs

(. 123)
     ⇒ 123

(read "(. 123)")
     ⇒ 123

Parece que Emacs simplemente lee (. 123)como 123, ¿qué pasó?

elisp list read

— xuchunyang
fuente

.No es una función. .No es una variable. No pasó nada: zip, cero, cero, nada.

— abogados el

@lawlist Parece ser un poco más complicado que eso. Por ejemplo, qsdftampoco es una función, pero (qsdf 123)rinde void function.... Y (. 123 456)produce un error de sintaxis ". in wrong context".

— T. Verron

A mí me parece un caso marginal ...

— wasamasa

Por cierto, el equivalente de bash .(o source) en elisp es probablemente load.

— T. Verron

(. 123)en tutorialspoint.com/execute_lisp_online.php da *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER #P"main.lisp" @1>: token "." not allowed here. En emacs: (boundp '.)→ nily (fboundp '.)→ nil. Es decir, el efecto descrito por usted es muy extraño!

— Tobias

Parece que Emacs simplemente lee (. 123) como 123, ¿qué pasó?

Eso es exactamente lo que pasó. Para respaldarlo con fuentes:

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");
  }

Este es el caso especial de read_listin lread.c. Normalmente a . se trata estableciendo el cdr de la cola previamente leída por lo que sigue. Sin embargo, en el caso de que no haya cola (como cuando se lee (. 123)), lo siguiente se lee y se devuelve como está. Personalmente, esperaría que eso condujera a un error de sintaxis no válido, pero estoy seguro de que alguien puso el caso especial allí para solucionar fuentes particularmente terribles. He probado cómo se comportan otros intérpretes de Lisp por diversión y ninguno de ellos csi, pily sbclpermiten leer esto, por lo que puede valer la pena un informe de error.

editar: Guile se comporta igual, MIT-Scheme no. Ahí va mi teoría de que este comportamiento es algo GNU ...

— wasamasa
fuente

¿No es Guile GNU también?

— T. Verron el

Sí, pero también lo es MIT-Scheme en estos días.

— wasamasa

Por favor considere reportar un error de Emacs. Este no es un comportamiento Lisp "normal". Además, parece ser un comportamiento indocumentado.

— Dibujó el

Informé esto en el error # 24875 .

— xuchunyang