Signification de période en (. 123)

J'ai appris . /path/to/fileen bash est utilisé pour exécuter un fichier. Par curiosité, j'évalue quelque chose comme ce qui suit dans Emacs

(. 123)
     ⇒ 123

(read "(. 123)")
     ⇒ 123

Il ressemble à Emacs lit tout simplement (. 123)que 123, ce qui est arrivé?

elisp list read

— xuchunyang
source

.n'est pas une fonction. .n'est pas une variable. Rien ne s'est passé - zip, zéro, zilch, nada.

— lawlist

@lawlist Cela semble être un peu plus compliqué que ça. Par exemple, ce qsdfn'est pas une fonction non plus, mais (qsdf 123)cède void function.... Et (. 123 456)renvoie une erreur de syntaxe ". in wrong context".

— T. Verron

Cela ressemble à un cas de bord dans le lecteur pour moi ...

— wasamasa

Btw, l'équivalent de bash .(ou source) dans elisp est probablement load.

— T. Verron

(. 123)sur tutorialspoint.com/execute_lisp_online.php donne *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER #P"main.lisp" @1>: token "." not allowed here. Dans emacs: (boundp '.)→ nilet (fboundp '.)→ nil. C'est à dire, l'effet décrit par vous est très étrange!

— Tobias

On dirait qu'Emacs lit simplement (. 123) comme 123, que s'est-il passé?

C'est exactement ce qui s'est passé. Pour le sauvegarder avec des 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");
  }

C'est le cas particulier de read_listin lread.c. Normalement, a . est traité en définissant le cdr de la queue précédemment lue par ce qui suit. Cependant, dans le cas où il n'y a pas de queue (comme lors de la lecture (. 123)), la prochaine chose est lue et retournée telle quelle. Personnellement, je m'attendrais à ce que cela conduise à une erreur de syntaxe non valide, mais je suis sûr que quelqu'un a mis le cas spécial là pour contourner des sources particulièrement terribles. J'ai essayé comment les autres interprètes Lisp se comportent pour le plaisir et rien de tout cela csi, pilet sbclj'autorise la lecture de cela, donc cela peut valoir un rapport de bogue.

edit: Guile se comporte de la même manière, MIT-Scheme ne fonctionne pas. Il va ma théorie de ce comportement étant une chose GNU ...

— wasamasa
source

N'est-ce pas aussi Guile GNU?

— T. Verron

Oui, mais le MIT-Scheme l'est aussi de nos jours.

— wasamasa

Veuillez envisager de signaler un bogue Emacs. Ce n'est pas un comportement Lisp "normal". De plus, il semble s'agir d'un comportement non documenté.

— Drew

J'ai signalé cela dans le bogue # 24875 .

— xuchunyang