guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark H Weaver
Subject: Re: Fix reader options for R6RS `get-datum'
Date: Wed, 12 Dec 2012 18:48:07 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

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.

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

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

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?

   Regards,
     Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]