Gleefre

Also note that *not* defining such an extension leads to losing print-read consistency, since a symbol in a package named `""` no longer can be readably printed. Such a symbol...

There is a similar problem with potential numbers (see [CLHS 2.3.1.1.1](https://www.lispworks.com/documentation/HyperSpec/Body/02_caaa.htm)). The example of interest here is `5||`, which is specifically said to be interpreted as a symbol. However, the...

I don't claim that `5||` is undefined -- it is indeed specifically said to be read as a symbol. However, the reason why it is not interpreted as a number...

A few passages, including the one that I have already cited earlier from CLHS 2.3.1.1.1, suggest that escape characters should be part of the token. Here's another passage that supports...

> a token must also remember that it has occurrences of multiple-escapes And that contradicts the hyperspec, as [CLHS 2.2 Reader Algorithm](https://www.lispworks.com/documentation/HyperSpec/Body/02_b.htm) explicitly specifies how tokens are constructed (the phrases...

> Keeping the escapes themselves is not really useful and makes parsing the token more difficult, once the token type is determined from the traits. Just in case, by saying...

> "As IF". Well, there are many other examples. Here's what I have found so far (including previous ones for completeness): [CLHS 2.1.4 Character Syntax Types](https://www.lispworks.com/documentation/HyperSpec/Body/02_ad.htm): > Constituent and escape...

About the 2nd point. IIUC the standard says that `||:xxxx` should be read as a keyword. (See a longer explanation in the WSCL issue.) However, reading it as a symbol...

Sorry, forgot that I have built mkcl from master/head at some point. I have updated it to current head, same results with the macroexpand-all test. ```lisp (lisp-implementation-version) ; => "1.1.11.206-b414811"...