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:
- 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).