[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix reader options for R6RS `get-datum'
From: |
Andreas Rottmann |
Subject: |
Re: Fix reader options for R6RS `get-datum' |
Date: |
Fri, 14 Dec 2012 04:22:24 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
Mark H Weaver <address@hidden> writes:
> Hi Andreas,
>
> Andreas Rottmann <address@hidden> writes:
>> Mark H Weaver <address@hidden> writes:
>>> Andreas Rottmann <address@hidden> writes:
>>>> This patch series addresses the problem that `get-datum' is using the
>>>> global reader options, even for those options that have to have fixed
>>>> values to make the reader behave in an R6RS-compatible way.
>>>
>>> I'm sorry to have not done so earlier, but I finally looked at the R6RS
>>> specification for 'get-datum', and I don't see anything to suggest that
>>> it should recognize a different notation than 'read' does.
>>>
>> I think it does. But in the place where one would expect, namely the
>> docs on `get-datum' (8.2.6), it does not say it as clearly as one would
>> like:
>>
>> Reads an external representation from textual-input-port and returns
>> the datum it represents. The get-datum procedure returns the next
>> datum that can be parsed from the given textual-input-port, updating
>> textual-input-port to point exactly past the end of the external
>> representation of the object.
>
> Section 8.3 defines 'read' as follows:
>
> Reads an external representation from textual-input-port and returns
> the datum it represents. The read procedure operates in the same way
> as get-datum, see section 8.2.9.
>
> I believe this last sentence clearly confirms my belief that 'read' and
> 'get-datum' should recognize the same syntax.
>
Well yes, R6RS `read' and R6RS `get-datum' need to understand the same
syntax, but I thought you were talking about Guile `read' and R6RS
`get-datum'.
>>
>>> Maybe what we should have instead is a command-line option that sets
>>> some(?) of the global read options to conform with R6RS.
>>>
>>> What do you think?
>>>
>> I disagree quite strongly -- IMO, `get-datum' must, for every valid
>> datum, according to R6RS lexical syntax, return the Scheme data denoted
>> by that external representation. By that rule, one must fix the values
>> of reader options which would otherwise lead to valid R6RS external
>> representations being read as a datum different from the one which would
>> result according to R6RS syntax.
>
> I agree that there should be an easy way to set the reader options so
> that all of the R6RS external representations are read as specified.
>
Yes, but this cannot be a program-global switch -- it is simply defined
behavior `get-datum', which must *not* be affected by any global
switches. An R6RS syntax commandline switch would make sense regardless,
for dealing with e.g. script syntax, but this is a completely orthogonal
issue, and I'd like to concentrate on the `get-datum' correctness issue
for now.
> IMO, this needs to be done not only for 'get-datum' but also for 'read',
> hence my suggestion to provide some way to set the global read options
> appropriately.
>
Yup, R6RS `read' needs to be implemented in terms of `get-datum', not
only because of reader options, but also because of the required
exception behavior. This is how it's done already -- see
modules/rnrs/io/simple.scm.
> On the flip side, if someone has enabled SRFI-105 curly-infix
> expressions, or any other reader extension that does not conflict with
> standard R6RS notation, then both 'get-datum' and 'read' should honor
> that setting.
>
> Does that make sense?
>
It does, and I think this is also what my patch implements, if I
understood both the code and your words correctly :-).
Regards, Rotty
--
Andreas Rottmann -- <http://rotty.xx.vu/>