My opinion is that two approaches are incompatible. Problem is the same I have noted before: (in-package) form leads to implicit (and sometimes unpredictable) change of current readtable in SLIME.
why would it be unpredictable? if there's a relevant entry in *readtable-alist*, then it changes the current readtable only in the dynamic extent of an operation (as opposed to e.g. globally, or in the dynamic extent of the REPL, or sumesuch). i don't see the problem: compile-toplevel-form and friends look for an in-package form higher up in the buffer, does the usual dance which includes optionally rebinding whatever *readtable-alist* says as the current readtable. then the same is done for an in-readtable form, which may rebind another readtable and thus override *readtable-alist*. and then the whole thing is forgotten when the compilation is finished and the stack is unwound. IOW, the two can live next to each other independently, in-readtable having priority over *readtable-alist*. or am i missing something?
I think more discussion is required. First I thought I could suggest a mode switch which alters behaviour of (in-readtable), but it is implicit and this is bad. So second suggestion is the following: 1. Create new form, say (in-readtbl) which changes readtable, but does not affect *readtable-alist* 2. Create variable, *lock-readtable-alist*. If it is true, error is signalled on attempt to alter *readtable-alist* 3. Display readtable name on modeline.
IMO, this is way too much unjustified complexity (or i'm missing something). -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “If it's not worth doing, it's not worth doing well” — Donald Hebb