unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw@netris.org>
Cc: guile-devel@gnu.org
Subject: Re: Needed: per-port reader options
Date: Thu, 18 Oct 2012 18:20:36 +0200	[thread overview]
Message-ID: <87mwzjwy3v.fsf@gnu.org> (raw)
In-Reply-To: <87y5j5srek.fsf@tines.lan> (Mark H. Weaver's message of "Tue, 16 Oct 2012 23:34:27 -0400")

Hi Mark!

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (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’.



  reply	other threads:[~2012-10-18 16:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-13 18:51 Needed: per-port reader options Mark H Weaver
2012-10-16 15:52 ` Ludovic Courtès
2012-10-16 20:22   ` Mark H Weaver
2012-10-16 21:39     ` Ludovic Courtès
2012-10-16 21:57       ` Noah Lavine
2012-10-16 22:01         ` Ludovic Courtès
2012-10-17  3:34       ` Mark H Weaver
2012-10-18 16:20         ` Ludovic Courtès [this message]
2012-10-18 17:48           ` Mark H Weaver
2012-10-19  2:12             ` Mark H Weaver
2012-10-21 21:40               ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mwzjwy3v.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guile-devel@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).