Edit history: 2004-07-20, Version 1 by Bruno Haible
Status: For CLiki consideration
- Problem Description:
- There is confusion about the meaning of a NIL element in a macro lambda list and destructuring lambda list. One should confirm or disconfirm that NIL in a destructuring lambda list (or a macro lambda list) acts as a "don't care" symbol, matching any object without causing a binding.
- Proposal (DESTRUCTURING-NIL:DISALLOW):
- Make it explicit that NIL as element of a macro lambda list or destructuring lambda list that has no lambda list keywords denotes the variable NIL, which is not useful since NIL being a constant, it cannot be bound or assigned.
- Proposal (DESTRUCTURING-NIL:ATOMIC):
- Make it explicit that NIL as element of a macro lambda list or destructuring lambda list that has no lambda list keywords is allowed and matches only the NIL object, but produces no variable bindings.
- Proposal (DESTRUCTURING-NIL:WILDCARD):
- Make it explicit that NIL as element of a macro lambda list or destructuring lambda list that has no lambda list keywords matches any object, but produces no variable bindings.
- Test case:
- (macrolet ((%m (nil) :good)) (%m nil))
(macrolet ((%m (nil) :good)) (%m t))
- CLHS 3.4.4 points to ATOMIC, since "tree structure" distinguish between cons and atom, and NIL is an atom.
- Current practice:
- CLISP has been implementing DISALLOW for years and has now switched to ATOMIC.
- Cost to Implementors:
- Change the handling of macro- and destructuring lambda lists.
- Cost to Users:
- None, since relying on any of these behaviours has already been obscure.
- Cost of Non-Adoption:
- Continued confusion.
- Bruno Haible votes for ATOMIC, since it preserves the symmetry between the destructuring lambda lists (X . NIL) and (NIL . X), while the other proposals don't.
- Kalle Olavi Niemitalo says about WILDCARD: Why would it do that, other than in LOOP destructuring?
- Thomas F. Burdick: Section 22.214.171.124 explains in the large how destructuring should work, and it uses the term "list", not cons. This is inconsistent in the spec (126.96.36.199.1 proceeds to refer to symbols in implicit contrast to lists), but 188.8.131.52 is where one should look to understand the syntax of destructuring lambda lists. The duplicate verbiage elsewhere in the text which implies the possibility of ATOMIC should be replaced by references to 184.108.40.206.
- Thomas F. Burdick strongly disagrees with the "Cost to users" section. Any change except ATOMIC will be at odds with all existing implementations in wide use. Any non-CLISP users will likely find many problems in existing macros.