Mark H Weaver <m...@netris.org> writes: > Hi Andreas, > > Andreas Rottmann <a.rottm...@gmx.at> writes: >> Mark H Weaver <m...@netris.org> writes: >>> Andreas Rottmann <a.rottm...@gmx.at> 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/>
