On Apr 14, 2015, at 6:57 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> 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.
Do you mean 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))
#\# 'non-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()")))) ; '#hash()
Because this worked!
I’m surprised though; how is it communicating the orig-readtable to the #hash
reader macro so that it can use that for parsing the ()?
This doesn’t work, though:
(parameterize ([current-readtable ….])
(println (read (open-input-string "#hash((a . b))")))) ; . read: expected or
`[' or `{' to start a hash pair
If I replace the inner set of parens with brackets, it works.
> 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.
Would this require giving an extra argument to reader macro procedures, or am I
misunderstanding something?
> 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.
