Re: WG: Recovering the once true meaning of type NIL in LOOP

[Bruno H. <br...@cl...>]

Hi Don,

>  > Here you have assumed that the type specifier has a list structure
>  > with some kind of "optional" semantics. However, 6.1.1.7 is clear about:
> 
> Not sure what you mean by optional semantics - if there is nothing
> matching some variable then I don't want it assigned a type.

Yes, this is what I mean. This is not written in CLHS 6.1.1.7.

What is written is:
  (A) A type specifier for a destructuring pattern is a tree of type specifiers
  (B) same shape as the tree of variable names, with the following exceptions:
  (C) When aligning the trees, an atom in the tree of type specifiers that
      matches a cons in the variable tree declares the same type for each
      variable in the subtree rooted at the cons.
  (D) A cons in the tree of type specifiers that matches an atom in the tree of
      variable names is a compound type specifier.

By (A), we have to view the variables and type specifier as trees:
  (i . (j . (k . nil)))  and  (fixnum . nil)

By (B), fixnum matches i
and     nil    matches (j . (k . nil))

By (C), nil    matches j
and     nil    matches (k . nil)

By (C) again,  nil matches k.

> You could argue that (j) matches nil, but in that case I'd expect
> that the semantics of a single symbol matching a list should 
> specifically exclude nil as the symbol.

The rules don't talk about "a list". They talk about trees, atoms, and conses.

Bruno