Stephen Compall writes:
[Issue WITH-READTABLE-ITERATOR:]
In spirit of CLHS 3.6, consequences are undefined if READTABLE is modified except for modification of the current macro character under traversal.
What rules are there for modification when modifying the current macro character? Under the CCL implementation:
Good call. SET-MACRO-CHARACTER, and SET-DISPATCH-MACRO-CHARACTER are allowed to be invoked on the current macro char (second return value.)
All other operations may alter the inners of the readtable in a way that could lead to strange behaviour.
I'll also substitute "consequences are undefined" with "consequences are unspecified"; this makes it more clear that implementations can loose the constraints, if it suits their representation of readtables.
Likewise, there should also be a rule about modifying structure obtained via the generator.
Indeed, it should!
ยน ANSI for set-macro-character and set-dispatch-macro-character does not seem to specify what passing NIL as the function means, by my brief research, or even to allow it (as NIL is not a function designator).
That is true. The portable way to "disable" a reader macro character is to use
(set-syntax-from-char to-char #\A to-readtable (copy-readtable nil))
-T.