[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Needed: per-port reader options
From: |
Ludovic Courtès |
Subject: |
Re: Needed: per-port reader options |
Date: |
Thu, 18 Oct 2012 18:20:36 +0200 |
User-agent: |
Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) |
Hi Mark!
Mark H Weaver <address@hidden> skribis:
> address@hidden (Ludovic Courtès) writes:
[...]
>> Of course. I just meant that, if you can call ‘make-reader’ with
>> whatever options you’re interested in, instead of globally changing the
>> reader’s option as is currently the case, then you’re halfway through.
>>
>> And in that case, the reader doesn’t need to be associated with the
>> port. Instead, since ‘primitive-load’ honors ‘current-reader’, it just
>> needs to be set when loading a file. This way, any changes to the
>> reader’s options will be local to that file.
>
> I see a few problems with that.
>
> First of all, since the reader directives can be placed anywhere that
> comments are permitted, the read options must be changed while the
> reader is in the middle of reading a single datum,
Yes, but the reader can modify its own options data structure.
[...]
> In other words, if a program uses 'read' on a data file, the
> reader directives '#!fold-case' et al should affect all future calls to
> 'read' on that file.
Just on that file, or on any file subsequently loaded?
> Fluids cannot solve this problem, because the program might be
> performing interleaved reads of multiple files within the same thread.
SRFI-105 reads:
An implementation of this SRFI MUST accept the marker #!curly-infix
followed by a whitespace character in its standard datum readers [...]
After reading this marker, the reader MUST accept curly-infix
expressions in subsequent datums until it reaches an end-of-file [...]
To me, this sounds like global reader options (reset on EOF), not like
per-port options.
>> Concretely, this would mean changing read.c such that each token reader
>> takes the reader options as an additional first parameter. Instead of
>> looking up the global ‘scm_read_opts’, they would look at this explicit
>> parameter.
>
> This is almost exactly what my patch does. I added an explicit
> parameter of type 'scm_t_read_opts *' to most of the helper functions in
> read.c, and that parameter is consulted instead of the global options.
I like it.
> When reader directives such as '#!fold-case' are encountered, both the
> 'scm_t_read_opts' struct and the per-port options are mutated.
>
> 'scm_read' initializes a local 'scm_t_read_opts' struct based on both
> the global read options and the per-port overrides (if any), and a
> pointer to that struct is passed down to all the helper functions in
> read.c that need it.
>
> What do you think?
The patch you posted (“Implement per-port reader options, #!fold-case
and #!no-fold-case.”) does all three things at once: (1) explicit
instead of global reader options, (2) per-port reader options, and (3)
fold-case.
Do you think you could split it into 3 patches? I’m happy with (1) and
(3). I remain skeptical about (2), because of the mixture of concerns.
Sorry for the extra work, but thank you for pushing these things!
Ludo’.
- Needed: per-port reader options, Mark H Weaver, 2012/10/13
- Re: Needed: per-port reader options, Ludovic Courtès, 2012/10/16
- Re: Needed: per-port reader options, Mark H Weaver, 2012/10/16
- Re: Needed: per-port reader options, Mark H Weaver, 2012/10/16
- Re: Needed: per-port reader options,
Ludovic Courtès <=
- Re: Needed: per-port reader options, Mark H Weaver, 2012/10/18
- Re: Needed: per-port reader options, Mark H Weaver, 2012/10/18
- Re: Needed: per-port reader options, Ludovic Courtès, 2012/10/21