Ý nghĩa của khoảng thời gian trong (. 123)

Tôi đã học . /path/to/filetrong bash được sử dụng để thực thi một tập tin. Vì tò mò, tôi đánh giá một thứ như sau trong Emacs

(. 123)
     ⇒ 123

(read "(. 123)")
     ⇒ 123

Dường như Emacs chỉ đơn giản là đọc (. 123)như 123, những gì đã xảy ra?

elisp list read

— xuchunyang
nguồn

.không phải là một chức năng. .không phải là một biến. Không có gì xảy ra - zip, zero, zilch, nada.

— luật

@lawlist Có vẻ phức tạp hơn thế một chút. Ví dụ, qsdfkhông phải là một chức năng, nhưng (qsdf 123)sản lượng void function.... Và (. 123 456)mang lại một lỗi cú pháp ". in wrong context".

— T. Verron

Trông giống như một trường hợp cạnh trong người đọc đối với tôi ...

— wasamasa

Btw, tương đương với bash's .(hoặc source) trong elisp có lẽ load.

— T. Verron

(. 123)trên guidespoint.com/execute_lisp_online.php cung cấp *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER #P"main.lisp" @1>: token "." not allowed here. Trong emacs: (boundp '.)→ nilvà (fboundp '.)→ nil. Tức là, hiệu ứng được mô tả bởi bạn là rất lạ!

— Tobias

Có vẻ như Emacs chỉ đơn giản đọc (123) là 123, chuyện gì đã xảy ra?

Đó chính xác là những gì đã xảy ra. Để sao lưu nó với các nguồn:

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

Đây là trường hợp đặc biệt cho read_listtrong lread.c. Thông thường a . được xử lý bằng cách đặt cdr của đuôi đã đọc trước đó bằng bất cứ điều gì sau đây. Tuy nhiên trong trường hợp không có đuôi (như khi đọc (. 123)), điều tiếp theo được đọc và trả lại như cũ. Cá nhân, tôi hy vọng điều đó sẽ dẫn đến một lỗi cú pháp không hợp lệ, nhưng tôi chắc chắn rằng ai đó đã đặt trường hợp đặc biệt ở đó để xử lý các nguồn khủng khiếp đặc biệt. Tôi đã thử làm thế nào các thông dịch viên Lisp khác hành xử cho vui và không ai trong số đó csi, pilvà cho sbclphép đọc điều này, vì vậy nó có thể đáng báo cáo lỗi.

chỉnh sửa: Guile hành xử giống nhau, MIT-Scheme thì không. Có lý thuyết của tôi về hành vi này là một điều GNU ...

— wasamasa
nguồn

GNU Guile có tốt không?

— T. Verron

Vâng, nhưng MIT-Scheme ngày nay cũng vậy.

— wasamasa

Vui lòng xem xét báo cáo lỗi Emacs. Đây không phải là hành vi Lisp "bình thường". Hơn nữa, nó dường như là hành vi không có giấy tờ.

— vẽ

Tôi đã báo cáo điều này trong lỗi # 24875 .

— xuchunyang