Znaczenie okresu w (. 123)

Dowiedziałem się, że . /path/to/filebash służy do wykonywania pliku. Z ciekawości ewaluuję coś w stylu Emacsa

(. 123)
     ⇒ 123

(read "(. 123)")
     ⇒ 123

Wygląda na to, Emacs po prostu brzmi (. 123)jak 123to, co się stało?

elisp list read

— Xuchunyang
źródło

.nie jest funkcją. .nie jest zmienną. Nic się nie stało - zip, zero, zilch, nada.

— prawnik

@lawlist To wydaje się nieco bardziej skomplikowane. Np. Też qsdfnie jest funkcją, ale (qsdf 123)daje void function.... I (. 123 456)powoduje błąd składniowy ". in wrong context".

— T. Verron,

Dla mnie

— wygląda to na skrajny przypadek

Btw, prawdopodobnie odpowiednik bash .(lub source) w elisp load.

— T. Verron,

(. 123)na tutorialspoint.com/execute_lisp_online.php daje *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER #P"main.lisp" @1>: token "." not allowed here. W emacs: (boundp '.)→ nili (fboundp '.)→ nil. Tj. Opisany przez ciebie efekt jest bardzo dziwny!

— Tobias

Wygląda na to, że Emacs po prostu czyta (. 123) jako 123, co się stało?

Właśnie tak się stało. Aby wykonać kopię zapasową za pomocą źródeł:

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

Jest to szczególny przypadek read_listw lread.c. Zwykle a . jest traktowane przez ustawienie cdr poprzednio czytanego ogona przez cokolwiek następuje. Jednak w przypadku, gdy nie ma ogona (jak podczas czytania (. 123)), następna rzecz jest czytana i zwracana w niezmienionej postaci. Osobiście spodziewałbym się, że doprowadzi to do nieprawidłowego błędu składniowego, ale jestem pewien, że ktoś umieścił tam specjalny przypadek, aby obejść szczególnie okropne źródła. Sprawdziłem, jak zachowują się inni tłumacze Lisp dla zabawy i żadnego z nich csi, pili sbclpozwalam na przeczytanie tego, więc warto zgłosić błąd.

edycja: Guile zachowuje się tak samo, schemat MIT nie. Istnieje moja teoria, że takie zachowanie jest GNU ...

— wasamasa
źródło

Czy Guile GNU też nie jest?

— T. Verron,

Tak, ale w dzisiejszych czasach tak też jest w systemie MIT.

— wasamasa,

Proszę rozważyć zgłoszenie błędu Emacsa. To nie jest „normalne” zachowanie Lisp. Co więcej, wydaje się to zachowaniem nieudokumentowanym.

— Drew

Zgłosiłem to w błędzie # 24875 .

— xuchunyang