Re: [PATCH] Make `get-datum' conform more closely to R6RS semantics

[Andreas Rottmann <a.rottmann@gmx.at>]

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/>