Arti titik dalam (. 123)

Saya pelajari . /path/to/filedi bash digunakan untuk mengeksekusi file. Hanya karena penasaran, saya eval sesuatu seperti yang berikut ini di Emacs

(. 123)
     ⇒ 123

(read "(. 123)")
     ⇒ 123

Sepertinya Emacs hanya dibaca (. 123)sebagai 123, apa yang terjadi?

elisp list read

— xuchunyang
sumber

.bukan fungsi. .bukan variabel. Tidak ada yang terjadi - zip, nol, zilch, nada.

— hukum

@lawlist Sepertinya sedikit lebih rumit dari itu. Misalnya qsdfbukan fungsi juga, tetapi (qsdf 123)menghasilkan void function.... Dan (. 123 456)menghasilkan kesalahan sintaksis ". in wrong context".

— T. Verron

Sepertinya kasus tepi di pembaca untuk saya ...

— wasamasa

Btw, mungkin setara dengan bash .(atau source) di elisp load.

— T. Verron

(. 123)di tutorialspoint.com/execute_lisp_online.php berikan *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER #P"main.lisp" @1>: token "." not allowed here. Dalam emacs: (boundp '.)→ nildan (fboundp '.)→ nil. Yaitu, efek yang dijelaskan oleh Anda sangat aneh!

— Tobias

Sepertinya Emacs hanya membaca (. 123) sebagai 123, apa yang terjadi?

Itulah tepatnya yang terjadi. Untuk mencadangkannya dengan sumber:

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

Ini adalah kasus khusus untuk read_listdi lread.c. Biasanya a . diperlakukan dengan mengatur cdr dari bacaan yang sebelumnya dibaca oleh apa pun yang berikut. Namun dalam kasus tidak ada ekor (seperti saat membaca (. 123)), hal berikutnya dibaca dan dikembalikan apa adanya. Secara pribadi, saya berharap itu mengarah pada kesalahan sintaksis yang tidak valid, tapi saya yakin seseorang meletakkan case khusus di sana untuk bekerja di sekitar sumber yang sangat mengerikan. Saya sudah mencoba bagaimana interpreter Lisp lain berperilaku untuk bersenang-senang dan tidak ada csi, pildan sbclmemang mengizinkan membaca ini, sehingga mungkin layak laporan bug.

sunting: Tipu muslihat sama, MIT-Skema tidak. Sudah ada teori saya tentang perilaku ini menjadi hal GNU ...

— wasamasa
sumber

Bukankah Guile GNU juga?

— T. Verron

Ya, tapi begitu juga MIT-Skema hari ini.

— wasamasa

Silakan pertimbangkan melaporkan bug Emacs. Ini bukan perilaku Lisp "normal". Terlebih lagi, tampaknya perilaku tidak berdokumen.

— Drew

Saya melaporkan ini dalam bug # 24875 .

— xuchunyang