This is the kind of problem that the readtable argument to
`read/recursive` was meant to solve, but I see that it doesn't work in
this case.

I have in mind that you'd map `#` to use `read/recursive` with a
readtable that restores the default `(`. Mapping `#` would cover hash
tables, vectors, and prefab structures.

As `read/recursive` is currently implemented, however, a given
readtable is would be used only for the initial `#`, so it doesn't
affect the `(`s that delimit hash-table entries. It would make sense
--- and I think it would solve your problem --- if the given readtable
instead applied to all of the delimiters of the non-nested parts of the
first datum in the input.


There are still plenty of limitations with the readtable-for-next-datum
feature. For example, I tried to make `~` start a form like `#`, except
that `<` and `>` are treated like parentheses for the immediate datum.
That doesn't really work, though; in

  ~hash<<a . b> <c . d>>

the `b` parsed with the original readtable (as intended), and so `b>`
is parsed together as a symbol (not as intended). That's not a problem
for your goal, since I think you're not adjusting `)`, but it
illustrates a limitation.


Overall, adding one more argument to `read/recursive` (to enable
readtable-for-next-datum mode) is easy enough to add, but the result
isn't pretty and it doesn't seem much more general. Does it sound
useful enough to you?


At Mon, 13 Apr 2015 16:51:45 -0400, "Alexander D. Knauth" wrote:
> Ok, I guess that makes sense.  
> 
> I do have `(` mapped to something other than the default, but not in a too 
> crazy way.
> 
> I’m making a readtable-based version of part of sweet-exp where f(x) reads as 
> (f x), but also I changed `(` so that (f)(x) reads as ((f) x), but (f) still 
> reads as (f), and ((x . 1) y (z . 2)) still reads as ((x . 1) y (z . 2)).
> 
> But does this mean that I can’t read hash-tables with this?  Or is there a 
> way 
> around it without reimplementing #hash, #hasheq, etc.?
> 
> Alex Knauth
> 
> On Apr 13, 2015, at 4:40 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> 
> > Ok, I oversimplified. The reader for `#hash` doesn't actually look for
> > `(`; it looks for any character that is mapped to the default meaning
> > of `(`.
> > 
> > For example, we could map `!` to the meaning of `(`, and the `#hash`
> > part of the reader would go along with that mapping:
> > 
> > (parameterize ([current-readtable
> >                 (make-readtable #f #\! #\( #f)])
> >   (read (open-input-string "#hash!!x . 1))")))
> > 
> > So, the issue in your example is that `(` is mapped to something other
> > than the default meaning of `(`.
> > 
> > At Mon, 13 Apr 2015 16:20:04 -0400, "Alexander D. Knauth" wrote:
> >> But if it does that, then why should it care whether the readtable entry 
> >> for 
> >> `(` is exactly the same as the default?
> >> 
> >> 
> >> On Apr 13, 2015, at 1:00 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> >> 
> >>> The reader for `#hash` parses parentheses and dots itself, instead of
> >>> recurring and checking the result, so that it can provide better error
> >>> reporting.
> >>> 
> >>> For example, if I write
> >>> 
> >>> #hash((x . 1) y (z . 2))
> >>> 
> >>> then the reader can highlight y and complain about that part
> >>> specifically. If the `#hash` part of the reader instead inspected the
> >>> result of a recursive `read`, then it wouldn't have source location for
> >>> "y", or it would have to recur in a way that preserved locations even
> >>> though the locations would be later discarded.
> >>> 
> >>> Also, checking after recurring would make it more difficult to report
> >>> errors left-to-right, such as getting an error about "]" instead of "y"
> >>> in
> >>> 
> >>> #hash((x . 1) y ]
> >>> 
> >>> It's difficult to say just how much those things matter, and there are
> >>> trade-offs in flexibility and error reporting, but that's why the
> >>> reader works the way it does currently.
> >>> 
> >>> At Sun, 12 Apr 2015 08:54:16 -0400, "Alexander D. Knauth" wrote:
> >>>> For something like this:
> >>>> #lang racket
> >>>> (define orig-readtable (current-readtable))
> >>>> (parameterize ([current-readtable
> >>>>               (make-readtable orig-readtable
> >>>>                               #\( 'terminating-macro
> >>>>                               (λ (c in src ln col pos)
> >>>>                                 (read-syntax/recursive src in c 
> >>>> orig-readtable)))])
> >>>> (println (read (open-input-string "()")))             ; ’()
> >>>> (println (read (open-input-string "#hash()"))))  ; . read: bad syntax 
> >> `#hash('
> >>>> 
> >>>> I can understand why this could be a problem, but why doesn't it work so 
> >> that 
> >>>> if reading the () produces the correct association list, it still works?
> >>>> 
> >>>> Otherwise is there any way around it without just reimplementing 
> >>>> #hash(), 
> >>>> #hasheq(), #hasheqv(), #(), etc. ?  
> >>>> 
> >>>> -- 
> >>>> 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.
> >> 
> >> -- 
> >> 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.

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

Reply via email to