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

[Andreas Rottmann]

Mark H Weaver <address@hidden> writes:

> Hi Andreas,
>
> 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.

Note that "external representation", referenced twice in the above text,
appears to be defined at the beginning of Chapter 4:

  Syntactic data (also called external representations) double as a
  notation for objects, and Scheme’s (rnrs io ports (6)) library [...]
  provides the get-datum and put-datum procedures for reading and
  writing syntactic data, converting between their textual
  representation and the corresponding objects.

This leads me to conclude that `get-datum' should parse R6RS syntax, as
defined in R6RS 4.2.1.  My proposed changes get us further in that
direction, by making sure we set all the knobs currently available to
enlarge the syntactic subset of R6RS we parse correctly, but it does not
get us to the finishing line.

> If the user has enabled reader extensions for 'read', I don't see why
> 'get-datum' shouldn't honor those extensions as well.
>
Well, there's difference between upwardly-compatible extensions, and
ones that are incompatible with R6RS syntax, such as colon-prefix or
colon-suffix keywords.  Hash-colon keywords are ok, since they don't
conflict with the interpretation of legal R6RS code.

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

Accepting lexical syntax which is not defined by R6RS is another matter,
and I'm fine with allowing it.

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.xx.vu/>