On Mon, 5 Apr 2021, [email protected] wrote:
But I'm not sure what you want here. There are a lot of examples in lint.scm (line 23201).
My point is, in a _general_ sense the current design of #readers makes it difficult to add new types of tokens, because of the 'read until next delimiter' behaviour.
Let's say, for example--not very practical, but you get the point--that I want an alternate syntax for character literals with #&x. Unlike #\, #& should only ever accept a single character; so #&a is the same as #\a, but #&Newline is the same as #\N ewline (latter is two tokens). Under the current scheme, the reader function will get passed "&Newline" as its parameter, and need to manually return (values #\N 'ewline). To make matters worse, a token can be split across the partially-read string and the input port; for instance, consider #&x#&(. This should be the same as #\x #\(, but the reader will pass the '&' sharp reader "&x#&", and "(" will be left on the input port; and the '&' sharp reader somehow has to reconstruct the result.
My proposal is to rectify this in a backwards-compatible way by checking the arity of #-readers; if a #-reader takes 1 parameter, the behaviour is the same as it is currently, but if it takes 0 parameters, then the reader will not read any characters past the first '#'.
-E _______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
