[cdr-discuss] Re: [RfC] WITH-READTABLE-ITERATOR

[Tobias C. Rittweiler]

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.