[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)

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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]