After some investigation, I’ve decided that this behavior is, indeed a bug, and I’ve opened a relevant bug report here: https://github.com/racket/racket/issues/1118
This brings me to a new and different question: how can I work around this? Even if the bug is fixed, it will only be fixed on whatever Racket version the fix makes it on to, and I’d like to maintain some backwards-compatibility with older versions for my library (so far I’ve managed to maintain compatibility back to 5.92). I tried adding a dispatch macro to a custom readtable that dispatches on #\;, but that doesn’t work because the reader doesn’t get that far to actually execute the reader extension. Is there any feasible way to fix this in a general sense without reimplementing the entire list reader? Or will I just have to not support this on current versions of Racket? > On Nov 2, 2015, at 8:36 PM, Alexis King <lexi.lam...@gmail.com> wrote: > > I came across some odd behavior today regarding readtables. Specifically, > (make-readtable base) seems to produce a readtable that is operationally > different from `base` when reading s-expression comments. Consider the > following code: > > ; this works > (read (open-input-string "(1 . 2 #;3)")) ; => '(1 . 2) > > ; this fails > (parameterize ([current-readtable (make-readtable (current-readtable))]) > (read (open-input-string "(1 . 2 #;3)"))) ; => read: illegal use of `.’ > > (see http://pasterack.org/pastes/48735 for a working demo) > > Is this a bug, or is it intentional? If it’s the latter, is it documented > anywhere? > > Alexis -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
