The new mode is not for old code. Changing any of the modes on
pre-existing code is likely to mess it up.
Did you read what I wrote? Perhaps you read but obviously did not
understand. Is nothing to do with old code is to do with implementation.
If readtable controls case of symbol names then changing readtable may
require change in case of symbol names and thus implementation must check
for this every time readtable is changed. This means every call to SET,
every incantation of (SETF (SYMBOL-VALUE ...) ...) must now check for this
And implementation must, when readtable is changed to toxic one, now deal
with what happens if it has two symbols whose names differ only in case.
Because implementation must do the right thing because this is standard so
must be language-quality. But is completely unclear what the right thing
is at all in this case.
Much worse, we all want native threads (we have native threads so that is
good). So now can have two threads with different readtables and thus
*different cases for symbol names at the same time*. Only hope would be to
force symbols to have two name slots and SYMBOL-NAME would need to check
the current readtable to know which one to look up.
This is all fucked up, and it is fucked up because the readtable is machine
which tells reader which data to construct or find corresponding to input
stream. Is not a place to control what the names of existing symbols are
and using it for that is stupid.
Not using readtable but some other mechanism is better. But is still hard
if that new mechanism is dynamic at all: still probably need two name
slots, still have problems of mixed-case.
Also you keep going on about how it is inconvenient to deal with symbols
with mixed case (or lower case). Why don't you just solve that problem in
- write tiny function which takes package (CL for eg) and computes other
package with lowercase symbols, all symbols in new package have plist entry
pointing at their parents (or store mapping in table elsewhere does not
- write slightly less tiny function which walks over a form produces new
form with symbols with pointers to old symbols substituted;
- write wrappers for load / compile / compile-file / eval / repl which use
Now you have something you can use in lowercase. Hard bit is second
function: is easy to deal with most cases but array literals any other
object which might contain symbols in code need to be copied and this is
fiddly. But this is fine system does not need to be language-quality can
just not handle these cases and decide that you never do these things in
code you write.
First two of these took me ten mins with second fn explicitly not dealing
with complicated cases. Third part would be more fiddly (remember it only
has to work: does not need to be language-quality), mostly because would
need to understand enough of SLIME etc to make that work properly.
What you are doing sounds like standard displacement activity: 'I have
problem I need to solve which I could solve but I don't want to so I will
propose vast changes to language which I know will never happen so I have
excuse not to solve problem'. Used to be really common behaviour by people
on CLL, glad to see nothing has changed.