From: Andreas Rottmann <a.rottmann@gmx.at>
To: Mark H Weaver <mhw@netris.org>
Cc: guile-devel@gnu.org
Subject: Re: [PATCH] Make `get-datum' conform more closely to R6RS semantics
Date: Tue, 06 Nov 2012 20:55:41 +0100 [thread overview]
Message-ID: <87txt25ww2.fsf@delenn.home.rotty.xx.vu> (raw)
In-Reply-To: <87objceixe.fsf@tines.lan> (Mark H. Weaver's message of "Mon, 05 Nov 2012 00:07:57 -0500")
Mark H Weaver <mhw@netris.org> writes:
> Hi Andreas,
>
> Andreas Rottmann <a.rottmann@gmx.at> writes:
>> * module/rnrs/io/ports.scm (get-datum): Set reader options to be more
>> compatible with R6RS syntax.
>>
>> With Guile's default reader options, R6RS hex escape and EOL escape
>> behavior is missing. This change enables the former via the
>> `r6rs-hex-escapes' option, and gets us closer to the latter by setting
>> `hungry-eol-escapes'.
>>
>> * test-suite/tests/r6rs-ports.test ("8.2.9 Textual input")["get-datum"]:
>> New tests.
>> ---
>> module/rnrs/io/ports.scm | 13 +++++++++++--
>> test-suite/tests/r6rs-ports.test | 28 ++++++++++++++++++++++++++++
>> 2 files changed, 39 insertions(+), 2 deletions(-)
>>
>> [... patch elided ... ]
>
> The problem with the approach above is that it sets the read options
> globally, which is obviously a bad idea in a multithreaded program.
>
Oops, yes. I was under the impression that the read options are stored
in a fluid, but I didn't verify that assumption.
> Until very recently there was no other practical option, but now 'read'
> starts by building a private struct 'scm_t_read_opts' and passes it down
> to all the helper functions explicitly. This was partly what enable
> per-port read options, which are now supported internally and accessible
> using reader directives such as #!fold-case, #!no-fold-case, and
> #!curly-infix. It also means that it is now feasible to provide another
> 'read' procedure that accepts a set of read options explicitly.
>
> I've been avoiding adding a public API for this, because I feel that the
> current 'read-options' API is poorly-designed and I'd rather take the
> opportunity to come up with a clean design.
>
> For now, I suggest that we add 'get-datum' as a C function in read.c,
> which initializes the 'scm_t_read_opts' as needed for R6RS.
>
Yup, I've seen that change while skimming over recent changes in
stable-2.0, and have come to the conclusion that a solution that would
directly call `read' with an R6RS set of options would be better. My
patch has originated some way back -- I'll rework it along the lines of
your proposal.
> Also, while we're on the subject, now that we have per-port read
> options, perhaps #!r6rs ought to set some of them instead of being a
> no-op. See 'scm_read_shebang' in read.c.
>
Yep, I think that's a good idea. This can also spare us from setting
them as part of an --r6rs command-line option, which I suggested in the
%load-extensions thread
<http://lists.gnu.org/archive/html/guile-devel/2012-11/msg00018.html>.
Regards, Rotty
--
Andreas Rottmann -- <http://rotty.yi.org/>
prev parent reply other threads:[~2012-11-06 19:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-04 23:59 [PATCH] Make `get-datum' conform more closely to R6RS semantics Andreas Rottmann
2012-11-05 5:07 ` Mark H Weaver
2012-11-05 17:52 ` Ludovic Courtès
2012-11-06 7:36 ` Improving the API for read options Mark H Weaver
2012-11-06 19:01 ` Ludovic Courtès
2012-11-11 7:56 ` Mark H Weaver
2012-11-06 19:55 ` Andreas Rottmann [this message]
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=87txt25ww2.fsf@delenn.home.rotty.xx.vu \
--to=a.rottmann@gmx.at \
--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).