Re: Fix reader options for R6RS `get-datum'

[Andreas Rottmann]

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