Self-quoting empty list #128

mnw commented 2023年07月26日 11:00:50 +02:00

As () is no valid expression, there is no well-founded reason why the empty list is not self-quoting like characters, numbers, strings, etc.

Every valid Scheme expression that is not a self-quoting literal is of the form <identifier> or (<keyword> . <datum>) or (<expression> . <datum>).

We can therefore make () a self-quoting literal, evaluating to the empty list. This increases the consistency of Scheme.

As `()` is no valid expression, there is no well-founded reason why the empty list is not self-quoting like characters, numbers, strings, etc. Every valid Scheme expression that is not a self-quoting literal is of the form `<identifier>` or `(<keyword> . <datum>)` or `(<expression> . <datum>)`. We can therefore make `()` a self-quoting literal, evaluating to the empty list. This increases the consistency of Scheme.

johnwcowan commented 2023年07月26日 11:59:49 +02:00

Empty lists were self-quoting at least up to R3RS; in R4RS they were explicitly made syntax errors. As usual, we don't know exactly why, but I am willing to believe that there was a good reason.

Empty lists were self-quoting at least up to R3RS; in R4RS they were explicitly made syntax errors. As usual, we don't know exactly why, but I am willing to believe that there was a good reason.

mnw commented 2023年07月26日 12:10:31 +02:00

Empty lists were self-quoting at least up to R3RS; in R4RS they were explicitly made syntax errors. As usual, we don't know exactly why, but I am willing to believe that there was a good reason.

Even if there was a good reason, it may very well be that there is no longer one, especially if we can't think of one.

> Empty lists were self-quoting at least up to R3RS; in R4RS they were explicitly made syntax errors. As usual, we don't know exactly why, but I am willing to believe that there was a good reason. Even if there *was* a good reason, it may very well be that there is no longer one, especially if we can't think of one.

dpk commented 2023年07月26日 13:30:04 +02:00

It would be worth asking people who are around at the time.

Personally I would be against restoring self-evaluating (), as requiring it to be quoted helps catch errors where something that was meant to be a procedure call was not filled in. This is a rare error when writing code by hand, but can help find faulty macro expansions: in Chibi I’ve occasionally had the ‘empty application’ error come out of a macro I was writing. If () were self-quoting, any problem with the macro would be somewhat more mysterious.

It would be worth asking people who are around at the time. Personally I would be against restoring self-evaluating `()`, as requiring it to be quoted helps catch errors where something that was meant to be a procedure call was not filled in. This is a rare error when writing code by hand, but can help find faulty macro expansions: in Chibi I’ve occasionally had the ‘empty application’ error come out of a macro I was writing. If `()` were self-quoting, any problem with the macro would be somewhat more mysterious.

aag commented 2023年07月26日 17:06:39 +02:00

Aren't there mailing list archives we could check?

Aren't there mailing list archives we could check?

mnw commented 2023年07月26日 17:56:19 +02:00

Empty lists were self-quoting at least up to R3RS; in R4RS they were explicitly made syntax errors. As usual, we don't know exactly why, but I am willing to believe that there was a good reason.

On page 7, top of the second column of the R3RS it says: "Note: In many dialects of Lisp, the empty combination, (), is a legitimate expression. In Scheme, combinations must have at least one sub expression, so () is not a syntactically valid expression."

So it seems that the empty list were not self-quoting in R3RS and that no change was made from R3RS to R4RS.

At least in/since R6RS, an expression of the form (<keyword> . <datum>) can be a syntactically valid expression so that the old identification of "combination = list" no longer holds. The cutting line is between pair and non-pairs. (Note also that R3RS speaks of "sub expression"; this no longer makes sense at least since R5RS when macros became an official part of the language.)

> Empty lists were self-quoting at least up to R3RS; in R4RS they were explicitly made syntax errors. As usual, we don't know exactly why, but I am willing to believe that there was a good reason. On page 7, top of the second column of the R3RS it says: "Note: In many dialects of Lisp, the empty combination, (), is a legitimate expression. In Scheme, combinations must have at least one sub expression, so () is not a syntactically valid expression." So it seems that the empty list were not self-quoting in R3RS and that no change was made from R3RS to R4RS. At least in/since R6RS, an expression of the form `(<keyword> . <datum>)` can be a syntactically valid expression so that the old identification of "combination = list" no longer holds. The cutting line is between pair and non-pairs. (Note also that R3RS speaks of "sub expression"; this no longer makes sense at least since R5RS when macros became an official part of the language.)

mnw commented 2023年07月27日 09:57:40 +02:00

I found the following in R2RS (page 29):

The () notation must be quoted in programs, however, because otherwise it would be a procedure call without a [sic] expression in the procedure position.

This is, of course, nonsense as the grammar for Scheme given on pages 6/7 does not classify () as a procedure call at all.

I found the following in [R2RS](https://dspace.mit.edu/bitstream/handle/1721.1/5600/AIM-848.pdf) (page 29): > The () notation must be quoted in programs, however, because otherwise it would be a procedure call without a [sic] expression in the procedure position. This is, of course, nonsense as the grammar for Scheme given on pages 6/7 does not classify `()` as a procedure call at all.

mnw commented 2023年07月28日 13:58:23 +02:00

The only well-founded reason I see that speaks against making () a self-quoting constant is that should we ever implement Racket's #%app and #%datum in Scheme, the expander could treat () as (#%app) or as (#%datum ()). We would remove the first option (which in this form looks not so unattractive) in the future if we made () a self-quoting constant now (unless the then-standard #%app is defined so that (#%app) evaluates to ()).

The only well-founded reason I see that speaks against making `()` a self-quoting constant is that should we ever implement Racket's `#%app` and `#%datum` in Scheme, the expander could treat `()` as `(#%app)` or as `(#%datum ())`. We would remove the first option (which in this form looks not so unattractive) in the future if we made `()` a self-quoting constant now (unless the then-standard `#%app` is defined so that `(#%app)` evaluates to `()`).

johnwcowan commented 2023年07月31日 03:29:04 +02:00

I think that's precisely the point being made by the various standards: that a pair is always #%app, never #%datum, and there is no reason why (#%app) should return (), or anything else.

I think that's precisely the point being made by the various standards: that a pair is always `#%app`, never `#%datum`, and there is no reason why `(#%app)` should return `()`, or anything else.

sham1 commented 2023年07月31日 06:18:45 +02:00

Another thing to consider is that allowing for a self-quoting () would be rather weird when we consider this in context of other Lisps. Other Lisps allow for this, so allowing this would be Scheme being different for the sake of being different.

Another thing to consider is that allowing for a self-quoting `()` would be rather weird when we consider this in context of other Lisps. Other Lisps allow for this, so allowing this would be Scheme being different for the sake of being different.

mnw commented 2023年07月31日 22:05:33 +02:00

I think that's precisely the point being made by the various standards: that a pair is always #%app, never #%datum, and there is no reason why (#%app) should return (), or anything else.

I am not convinced. The idea of Racket's #%app is that every expression of the form (...) is a macro use. If the first entry is not a keyword, #%app is inserted so that it becomes a macro use. But there were no macros in early Schemes.

Anyway, I checked the Racket documentation and if I read it correctly, () expands into a use of #%datum, which supports the initial idea in that () could be safely evaluated as a constant literal.

Another thing to consider is that allowing for a self-quoting () would be rather weird when we consider this in context of other Lisps. Other Lisps allow for this, so allowing this would be Scheme being different for the sake of being different.

I am confused. Do other Lisps evaluate () as the empty list or not?

> I think that's precisely the point being made by the various standards: that a pair is always #%app, never #%datum, and there is no reason why (#%app) should return (), or anything else. I am not convinced. The idea of Racket's `#%app` is that every expression of the form `(...)` is a macro use. If the first entry is not a keyword, `#%app` is inserted so that it becomes a macro use. But there were no macros in early Schemes. Anyway, I checked the Racket documentation and if I read it correctly, `()` expands into a use of `#%datum`, which supports the initial idea in that `()` could be safely evaluated as a constant literal. > Another thing to consider is that allowing for a self-quoting () would be rather weird when we consider this in context of other Lisps. Other Lisps allow for this, so allowing this would be Scheme being different for the sake of being different. I am confused. Do other Lisps evaluate `()` as the empty list or not?

johnwcowan commented 2023年07月31日 22:40:51 +02:00

I am not convinced. The idea of Racket's #%app is that every expression of the form (...) is a macro use. If the first entry is not a keyword, #%app is inserted so that it becomes a macro use.

Right. But () is precisely not a macro use.

Anyway, I checked the Racket documentation and if I read it correctly, () expands into a use of #%datum, which supports the initial idea in that () could be safely evaluated as a constant literal.

Sure it could. It could also be evaluated as the constant literal 0, or "null", or anything else. It's arbitrary to treat () as a datum and all other cases of (...) as macro calls.

I am confused. Do other Lisps evaluate () as the empty list or not?

They do. But that is because () is an alternative lexical syntax for the variable nil, which is constantly bound to the empty list. By CL convention, nil is false, () is used for things like empty lambda-lists, and `'()' is an empty-list datum.

> I am not convinced. The idea of Racket's `#%app` is that every expression of the form `(...)` is a macro use. If the first entry is not a keyword, `#%app` is inserted so that it becomes a macro use. Right. But `()` is precisely *not* a macro use. > Anyway, I checked the Racket documentation and if I read it correctly, `()` expands into a use of `#%datum`, which supports the initial idea in that `()` could be safely evaluated as a constant literal. Sure it could. It could also be evaluated as the constant literal `0`, or `"null"`, or anything else. It's arbitrary to treat `()` as a datum and all other cases of `(...)` as macro calls. >> I am confused. Do other Lisps evaluate `()` as the empty list or not? They do. But that is because `()` is an alternative lexical syntax for the variable `nil`, which is constantly bound to the empty list. By CL convention, `nil` is false, `()` is used for things like empty lambda-lists, and `'()' is an empty-list datum.

mnw commented 2023年07月31日 22:51:06 +02:00

Anyway, I checked the Racket documentation and if I read it correctly, () expands into a use of #%datum, which supports the initial idea in that () could be safely evaluated as a constant literal.

Sure it could. It could also be evaluated as the constant literal 0, or "null", or anything else. It's arbitrary to treat () as a datum and all other cases of (...) as macro calls.

It is not (non-empty) lists that are macro calls (in which case I would agree with your argument), but pairs (and identifiers).

I am confused. Do other Lisps evaluate () as the empty list or not?

They do. But that is because () is an alternative lexical syntax for the variable nil, which is constantly bound to the empty list. By CL convention, nil is false, () is used for things like empty lambda-lists, and `'()' is an empty-list datum.

So rebinding nil and evaluating () yields the value to which nil is bound? Is rebinding nil even possible?

> > Anyway, I checked the Racket documentation and if I read it correctly, `()` expands into a use of `#%datum`, which supports the initial idea in that `()` could be safely evaluated as a constant literal. > > Sure it could. It could also be evaluated as the constant literal `0`, or `"null"`, or anything else. It's arbitrary to treat `()` as a datum and all other cases of `(...)` as macro calls. It is not (non-empty) *lists* that are macro calls (in which case I would agree with your argument), but *pairs* (and identifiers). > > >> I am confused. Do other Lisps evaluate `()` as the empty list or not? > > They do. But that is because `()` is an alternative lexical syntax for the variable `nil`, which is constantly bound to the empty list. By CL convention, `nil` is false, `()` is used for things like empty lambda-lists, and `'()' is an empty-list datum. So rebinding `nil` and evaluating `()` yields the value to which `nil` is bound? Is rebinding `nil` even possible?

johnwcowan commented 2023年07月31日 23:14:50 +02:00

So rebinding nil and evaluating () yields the value to which nil is bound? Is rebinding nil even possible?

CL has a defconstant declaration, which declares a variable and assigns it to a specified variable. Constants can neither be assigned nor rebound. CL behaves as if the following declarations were present:

(defconstant nil 'nil)
(defconstant t 't)
(defconstant internal-time-units-per-second ...)
(defconstant array-dimension-limit 7) ; or more
(defconstant lambda-list-keywords '(&allow-other-keys,
 &aux, &body, &environment, &key, &optional, &rest,
 &whole))
(defconstant array-total-size-limit 1024) ; usually much larger
...

So no.

> So rebinding `nil` and evaluating `()` yields the value to which `nil` is bound? Is rebinding `nil` even possible? CL has a `defconstant` declaration, which declares a variable and assigns it to a specified variable. Constants can neither be assigned nor rebound. CL behaves as if the following declarations were present: ``` (defconstant nil 'nil) (defconstant t 't) (defconstant internal-time-units-per-second ...) (defconstant array-dimension-limit 7) ; or more (defconstant lambda-list-keywords '(&allow-other-keys, &aux, &body, &environment, &key, &optional, &rest, &whole)) (defconstant array-total-size-limit 1024) ; usually much larger ... ``` So no.

mnw commented 2023年08月01日 10:15:19 +02:00

So rebinding nil and evaluating () yields the value to which nil is bound? Is rebinding nil even possible?

CL has a defconstant declaration, which declares a variable and assigns it to a specified variable. Constants can neither be assigned nor rebound. CL behaves as if the following declarations were present:

(defconstant nil 'nil)
(defconstant t 't)
(defconstant internal-time-units-per-second ...)
(defconstant array-dimension-limit 7) ; or more
(defconstant lambda-list-keywords '(&allow-other-keys,
 &aux, &body, &environment, &key, &optional, &rest,
 &whole))
(defconstant array-total-size-limit 1024) ; usually much larger
...

So no.

Thanks for explaining this to me!

So Scheme would effectively just do what CL does if () were evaluated to the empty list. (That does not rule out a library exporting nil bound to syntax that evaluates to () as well.)

> > So rebinding `nil` and evaluating `()` yields the value to which `nil` is bound? Is rebinding `nil` even possible? > > CL has a `defconstant` declaration, which declares a variable and assigns it to a specified variable. Constants can neither be assigned nor rebound. CL behaves as if the following declarations were present: > > ``` > (defconstant nil 'nil) > (defconstant t 't) > (defconstant internal-time-units-per-second ...) > (defconstant array-dimension-limit 7) ; or more > (defconstant lambda-list-keywords '(&allow-other-keys, > &aux, &body, &environment, &key, &optional, &rest, > &whole)) > (defconstant array-total-size-limit 1024) ; usually much larger > ... > ``` > > So no. Thanks for explaining this to me! So Scheme would effectively just do what CL does if `()` were evaluated to the empty list. (That does not rule out a library exporting `nil` bound to syntax that evaluates to `()` as well.)

johnwcowan commented 2023年08月02日 01:44:16 +02:00

So Scheme would effectively just do what CL does if () were evaluated to the empty list.

Yes. But the decision to make () a syntax error is very old in Scheme, and the designers were well aware that in CL, Maclisp, Interlisp, Zetalisp, etc. etc. () was self-evaluating. I have not been able to find an explanation of why they did it, but R2RS says this:

'() nd #!null are notations for the empty list. The #!null notation does not have to be quoted in programs. The () notation must be quoted in programs, however, because otherwise it would be a procedure call without a expression in the procedure position.

Rationale: Because many current Scheme interpreters deal with expressions as list structures rather than as character strings, they will treat an unquoted () as though it were quoted. It is entirely possible, however, that some implementations of Scheme will be able to detect an unquoted () as an error.

I would think more than twice before reversing this decision after almost fifty years.

> So Scheme would effectively just do what CL does if `()` were evaluated to the empty list. Yes. But the decision to make `()` a syntax error is very old in Scheme, and the designers were well aware that in CL, Maclisp, Interlisp, Zetalisp, etc. etc. `()` was self-evaluating. I have not been able to find an explanation of why they did it, but R2RS says this: > `'() ` nd `#!null` are notations for the empty list. The `#!null` notation does not have to be quoted in programs. The `()` notation must be quoted in programs, however, because otherwise it would be a procedure call without a expression in the procedure position. > > Rationale: Because many current Scheme interpreters deal with expressions as list structures rather than as character strings, they will treat an unquoted `()` as though it were quoted. It is entirely possible, however, that some implementations of Scheme will be able to detect an unquoted `()` as an error. I would think more than twice before reversing this decision after almost fifty years.

phm commented 2026年04月24日 01:01:19 +02:00

WG2 voted unanimously against self-quoting empty lists in the 2025年11月21日 meeting.

WG2 voted unanimously against self-quoting empty lists in the 2025年11月21日 meeting.

jobol commented 2026年05月01日 18:51:20 +02:00

Empty list should not be quoted in definition of syntax. It creates a kind of schizophreny. IMO it should be explain somewhere that empty list must not be quoted in syntax pattern because there () is not '()

Empty list should not be quoted in definition of syntax. It creates a kind of schizophreny. IMO it should be explain somewhere that empty list must not be quoted in syntax pattern because there () is not '()