unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andreas Rottmann <a.rottmann@gmx.at>
To: Mark H Weaver <mhw@netris.org>
Cc: guile-devel@gnu.org
Subject: Re: Fix reader options for R6RS `get-datum'
Date: Wed, 12 Dec 2012 22:32:11 +0100	[thread overview]
Message-ID: <87txrr0xes.fsf@delenn.home.rotty.xx.vu> (raw)
In-Reply-To: <87boe09w3q.fsf@tines.lan> (Mark H. Weaver's message of "Tue, 11 Dec 2012 15:23:21 -0500")

Mark H Weaver <mhw@netris.org> writes:

> Hi Andreas,
>
> Andreas Rottmann <a.rottmann@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.

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



  reply	other threads:[~2012-12-12 21:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-09 12:47 Fix reader options for R6RS `get-datum' Andreas Rottmann
2012-12-09 12:47 ` [PATCH 1/3] Split r6rs-ports.c according to module boundaries Andreas Rottmann
2012-12-15  5:35   ` Mark H Weaver
2012-12-15  5:38   ` Mark H Weaver
2012-12-09 12:47 ` [PATCH 2/3] Add internal API to specify reader options at reader invocation Andreas Rottmann
2013-01-21 20:44   ` Andy Wingo
2012-12-09 12:47 ` [PATCH 3/3] Make `get-datum' conform more closely to R6RS semantics Andreas Rottmann
2013-01-21 20:48   ` Andy Wingo
2012-12-11 20:23 ` Fix reader options for R6RS `get-datum' Mark H Weaver
2012-12-12 21:32   ` Andreas Rottmann [this message]
2012-12-12 23:48     ` Mark H Weaver
2012-12-14  3:22       ` Andreas Rottmann
2012-12-16 22:12         ` Mark H Weaver
2012-12-17 19:05           ` Andreas Rottmann
2012-12-17 19:30             ` Noah Lavine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87txrr0xes.fsf@delenn.home.rotty.xx.vu \
    --to=a.rottmann@gmx.at \
    --cc=guile-devel@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).