Received: (at submit) by debbugs.gnu.org; 27 Nov 2019 12:34:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 27 07:34:16 2019 Received: from localhost ([127.0.0.1]:53645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iZwWN-0005kt-PV for submit <at> debbugs.gnu.org; Wed, 27 Nov 2019 07:34:16 -0500 Received: from lists.gnu.org ([209.51.188.17]:44047) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <tomas@HIDDEN>) id 1iZwWM-0005kk-JE for submit <at> debbugs.gnu.org; Wed, 27 Nov 2019 07:34:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55865) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <tomas@HIDDEN>) id 1iZwWL-0006le-8h for bug-guile@HIDDEN; Wed, 27 Nov 2019 07:34:14 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_NONE, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <tomas@HIDDEN>) id 1iZwWK-0001FU-7Y for bug-guile@HIDDEN; Wed, 27 Nov 2019 07:34:13 -0500 Received: from mail.tuxteam.de ([5.199.139.25]:44944) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from <tomas@HIDDEN>) id 1iZwWJ-00018s-Nk for bug-guile@HIDDEN; Wed, 27 Nov 2019 07:34:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:Date; bh=t4/AjAjjkl2hUnyhORxOKdSgSDCmY/Tqij0vfK8L47Q=; b=Fbhq85fzy5Zvwhsua/CHlf8ZKsP0jDHOI2pQtG/BhpVGw6uyFd3r+xTNkOUd+LL0xD61wjwzmuggF9XCtMXuEeIAaHAh9VfcNBYfOdCpFMebtzXGWHsz0t94WYbbKORawUSO/9zwuifD2CbPhwQ9p00gNKOUDo+U3QMFmtPN9Jh4fOm2Y0qB9c6zb4ghS1Y9f8Zsqv90zReqt6I9zRyOhC/TYIG3y66PdKWkobCB2r+3x/rBu59/AaonMmnwMGcXc1Ll70zl3EvpIdUk4mFe1ISt8F+kj3jDphZ2V9lyBxUdslGQhOZnN+SZj4QVK90VycsNI0bW091i/E7ChrouQQ==; Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from <tomas@HIDDEN>) id 1iZwWC-0001Ig-FN for bug-guile@HIDDEN; Wed, 27 Nov 2019 13:34:04 +0100 Date: Wed, 27 Nov 2019 13:34:04 +0100 To: bug-guile@HIDDEN Subject: Re: bug#38398: non-obvious SCM_EOF_VAL rationale Message-ID: <20191127123404.GE30482@HIDDEN> References: <20191127074436.e6gev22lgi2yqpkg@HIDDEN> <CAD2gp_T8h2X5JK9zS1aOnnZO7rMGnsvuPrfS9a3KoHO3A_QrOw@HIDDEN> <20191127120534.i6okeasqcaodpae6@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6e7ZaeXHKrTJCxdu" Content-Disposition: inline In-Reply-To: <20191127120534.i6okeasqcaodpae6@HIDDEN> User-Agent: Mutt/1.5.21 (2010-09-15) From: <tomas@HIDDEN> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 5.199.139.25 X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) --6e7ZaeXHKrTJCxdu Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2019 at 12:05:34PM +0000, Zefram via Bug reports for GUILE,= GNU's Ubiquitous Extension Language wrote: [...] > But please don't get sidetracked. This wasn't a feature request for > "#eof" [...] To be fair, you contributed strongly to this side-tracking. By waving a big red flag: "This poor design precludes RnRS specifying read syntax for any EOF object [...]" you yourself drew attention to the underlying issues of the design instead of keeping things focused to the documentation. I agree that the doc could improve in this case... Cheers -- tom=C3=A1s --6e7ZaeXHKrTJCxdu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAl3ebTwACgkQBcgs9XrR2kYz2QCfXErtKyhW/wKgsk2eYQgar/Mt NJoAn2ppf/9cLzxfw0JrWCglNpDiTRri =EKga -----END PGP SIGNATURE----- --6e7ZaeXHKrTJCxdu--
bug-guile@HIDDEN:bug#38398; Package guile.
Full text available.
Received: (at 38398) by debbugs.gnu.org; 27 Nov 2019 12:05:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 27 07:05:41 2019
Received: from localhost ([127.0.0.1]:53552 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1iZw4j-0000tC-2c
for submit <at> debbugs.gnu.org; Wed, 27 Nov 2019 07:05:41 -0500
Received: from river.fysh.org ([87.98.248.19]:38757 ident=Debian-exim)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <zefram@HIDDEN>) id 1iZw4h-0000t2-8l
for 38398 <at> debbugs.gnu.org; Wed, 27 Nov 2019 07:05:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fysh.org;
s=20170316; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:
Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=fVUol5/DT+TLEsee6crHaZay459cbL6eZbXyhTSIJJI=; b=0g0HR/ZJsME3e6iS4DTNetvdFf
5jWwu6lIPn3d63Wc+jEHHQob7lFb+CuWDr/jQkOoDKthzBn2bPrJnKaZ5FEhNcsYPm/wbVkmMPwxc
++yL6hjR1hnjx6YI8eDCIvwvUMlJjLwmSeFObcHDcu8R90xkYLKdfhPtVNy2k6WVpgYQ=;
Received: from zefram by river.fysh.org with local (Exim 4.89 #1 (Debian))
id 1iZw4c-0002ct-JO; Wed, 27 Nov 2019 12:05:34 +0000
Date: Wed, 27 Nov 2019 12:05:34 +0000
From: Zefram <zefram@HIDDEN>
To: John Cowan <cowan@HIDDEN>
Subject: Re: bug#38398: non-obvious SCM_EOF_VAL rationale
Message-ID: <20191127120534.i6okeasqcaodpae6@HIDDEN>
References: <20191127074436.e6gev22lgi2yqpkg@HIDDEN>
<CAD2gp_T8h2X5JK9zS1aOnnZO7rMGnsvuPrfS9a3KoHO3A_QrOw@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAD2gp_T8h2X5JK9zS1aOnnZO7rMGnsvuPrfS9a3KoHO3A_QrOw@HIDDEN>
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 38398
Cc: 38398 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
John Cowan wrote:
>On the contrary: the EOF object is not a character, but it *can* be
>returned by read-char .
Bother. Of course I meant "can't be returned by read-char in a non-EOF
situation". I was alluding precisely to it being distinguishable from
characters for the purposes of that return convention.
> However, section 4.1 says that Guile is
>fully compliant with R5RS.
And yet, as I noted, it's actually non-compliant, in a way that's directly
relevant to this issue.
>Why do you believe it to be a poor design?
Because it makes it impossible to distinguish between reaching EOF and
reading a value that is otherwise a perfectly good one. Or, from the
other point of view, because it requires that read syntax be crippled
specifically to prevent this one value ever being a genuine result
of reading. read-char is free to use a distinguished return value
for EOF because the things it can read in a non-EOF situation form an
obviously-constrained subset of values. The nature of the read function,
however, is that it can read basically any value, so there is no obvious
place for a distinguished value for EOF.
Although the RnRS read syntax doesn't cover absolutely all values,
when extending the read syntax it's quite easy, even unintentionally,
to make it capable of reading types of object that RnRS doesn't imagine
being readable. Indeed, not only does Guile have the occasionally-useful
"#.", which makes absolutely all values readable, it's also got the
read-hash-extend system, which invites casual extension, and does nothing
to prevent user extensions returning the EOF object.
So it makes much more sense to embrace the ability of read to read
any value whatsoever, and to use some other mechanism to signal EOF.
Common Lisp, for example, which has "#." as standard, specifies that
read is to signal an error by default if it's at EOF.
> It seems quite appropriate to
>me for the EOF object not to be a datum value, for the same reason that it
>should not be a character. You nowhere state what purpose such a read
>syntax would serve.
You're making a bit of a leap here, if there's meant to be some causal
connection between these two sentences. By "such a read syntax" you seem
to be referring to my "#eof" suggestion, but the case against the RnRS
design of read doesn't depend at all on whether there's a read syntax
specifically for that object.
The use of a distinguished EOF return value from read, and the consequent
rationale for not having a specific read syntax for the EOF object, is
founded on the idea that read can't return the EOF object *at all* in a
non-EOF situation. This is undermined for Guile by the already-existing
"#." and read-hash-extend, without any need to invent new syntax.
To answer the second sentence in isolation: it would serve about the
same use as "#nil", making it easier to reference this useful object,
and extending the scope within which write-read round-tripping works.
I don't have strong feelings about having a specific read syntax,
it's just that this kind of distinguished object usually does have
specific syntax ("()", "#t", "#nil"). However, not every other object
like this has a read syntax; Guile's `unspecified' value is another one
that doesn't. (Tangent: the unspecified value could equally well do
with a read syntax, but through testing with "#.*unspecified*" I note
that at present weird behaviour results from actually reading it.)
> Do you wish to be able to use read to input a list of
>EOF objects, for instance? What would you do with them?
In code, I can imagine using a quoted EOF object in order to return
it from a function that's following something like read-char's return
convention, or to pass it to a function that expects values following
a similar convention. Also to pass it to something like memq, for the
purposes of testing a value that could be the EOF object. (A quoted
EOF object currently works in the interpreter but not in the compiler.)
In data, I imagine the EOF object would appear because of much the
same situations: it got returned from something like read-char, or it's
going to be fed to something that expects to occasionally receive the
EOF object. Stick them in a list? Sure, a list of values on its way
from A to B could well include an EOF object.
But please don't get sidetracked. This wasn't a feature request for
"#eof"; that's just an idea that idly arose from consideration of the
rationale in question. The issue that I'm seeking to get resolved is
that the documentation says the reason for the EOF object having no
specific read syntax is obvious, when in context it's really not.
-zefram
bug-guile@HIDDEN:bug#38398; Package guile.
Full text available.
Received: (at 38398) by debbugs.gnu.org; 27 Nov 2019 08:56:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 27 03:56:07 2019
Received: from localhost ([127.0.0.1]:53421 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1iZt7G-0002CE-RZ
for submit <at> debbugs.gnu.org; Wed, 27 Nov 2019 03:56:07 -0500
Received: from mail-qk1-f169.google.com ([209.85.222.169]:33065)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <cowan@HIDDEN>) id 1iZt7D-0002BY-Vp
for 38398 <at> debbugs.gnu.org; Wed, 27 Nov 2019 03:56:05 -0500
Received: by mail-qk1-f169.google.com with SMTP id c124so14383509qkg.0
for <38398 <at> debbugs.gnu.org>; Wed, 27 Nov 2019 00:56:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=ccil-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=3xM9NuBw1v9wqb9hLAYJqQmJlihbxPk1sm2ALhJEGlg=;
b=Wl4FVYqxJVrHfpjmo8RaXza4FfEIu36qZjcG0pyUNSu6PRAVnLMbdbG3yTbVFdPZ3u
Lu8diZ+Lc5HmBv0deo56LzEl06d+kZvpBQrVbbkCifx1vzHVND55kGQZ7EYbKCugaiU0
PCZL9mCPcN503dn26LfQEdODKr8XtH9OHhgYn9FWQO6WnBpIvHtq8yEjfx/2Mari5gG8
B9tTXszgTmm/261lbj+LezM6Nog9QYrt10L2dVBGV2thBHGiuXBkX4TOZNLht/C5i/sm
+t/2FBShjUwj0JHeeYmAX+muIzhZpRqJhGLv00fdldX4+NOOZ38b4A1eU7nvsWuSIjiQ
rlvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=3xM9NuBw1v9wqb9hLAYJqQmJlihbxPk1sm2ALhJEGlg=;
b=WHoBXn89DJ68UmpnTsezkFaPtBzpxHF6Pil0WgjlIDhO/dEP923JU521rwz3NuVKsX
8vk6S5AP71iKpC9udmJqGaVtC44Bb2I85ToDi9xK5hvfEauODcqHtxE0nsFaW9yePCWz
nFV9W91g5arf1YbX7NNBIW/XrrtDNsR41ETz+KWNdRr29CLrqIBgEqb0VGTweQyatqaI
AvG773tXACeCl7VI3sZQQn0kF7Z5lhF8G5lwhHII+0AUBhWB1KV+OgyDg2vpCLeEGY4m
sMWRWSpT8FJu6gu0ePH3199dAbxdgbK19cJCYnaw5rm55mz7O0MGqkxGJIu1V16dOqii
xjtg==
X-Gm-Message-State: APjAAAWp6rz8k+rIuqXrWbzXiL5wTTEwS+64X2p/VUBqYmbf4oHr2pLj
nCj5u67n/z+AdA9LHCy4X9ooFs3XRkf6G2T3lyz5l6m3jmk=
X-Google-Smtp-Source: APXvYqxeF/uPm6AdEp/V2Scp4mcVlSsNPANrPu43quSyPyXxOhDMEaSJCKVrEhaYxLr7elFya6fSGaTMR276iF65rjA=
X-Received: by 2002:a37:aa11:: with SMTP id t17mr3244788qke.60.1574844958234;
Wed, 27 Nov 2019 00:55:58 -0800 (PST)
MIME-Version: 1.0
References: <20191127074436.e6gev22lgi2yqpkg@HIDDEN>
In-Reply-To: <20191127074436.e6gev22lgi2yqpkg@HIDDEN>
From: John Cowan <cowan@HIDDEN>
Date: Wed, 27 Nov 2019 03:55:47 -0500
Message-ID: <CAD2gp_T8h2X5JK9zS1aOnnZO7rMGnsvuPrfS9a3KoHO3A_QrOw@HIDDEN>
Subject: Re: bug#38398: non-obvious SCM_EOF_VAL rationale
To: Zefram <zefram@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000004ff4790598502add"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 38398
Cc: 38398 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--0000000000004ff4790598502add
Content-Type: text/plain; charset="UTF-8"
On Wed, Nov 27, 2019 at 2:45 AM Zefram via Bug reports for GUILE, GNU's
Ubiquitous Extension Language <bug-guile@HIDDEN> wrote:
> It's fairly obvious
> that it's a value that can't be returned by read-char, and therefore is
> not itself a character, but that's quite a different matter.
On the contrary: the EOF object is not a character, but it *can* be
returned by read-char . Indeed it *is* returned by read-char just in case
read-char is called after the last character of its input port has been
read. This makes it possible to distinguish between two cases: read-char
returns a character if there are any in the input port, and the EOF object
if there are none.
By the same token, read can return either a datum value or an EOF object.
It returns a datum value if the remaining characters in its input port
constitute at least one datum (what R6RS calls an "external
representation") or the EOF object if no characters are available, and
raises an exception if the available characters do not constitute a datum.
An input port containing just "(", for example, will not return an EOF
object; it will raise an exception.
> The lack of
> s-expression representation actually comes from the entirely unobvious,
> and undocumented in Guile, use of the EOF value with the read function.
>
It's true that section 6.18.2 of the Guile 2.2.x manual is rather terse and
does not document this behavior. However, section 4.1 says that Guile is
fully compliant with R5RS. This means that it incorporates by reference
the R5RS specification, and in particular section 6.6.2, which restates at
greater length the rules I have given above. The definition of read in
R6RS defers to the definition of get-datum (both are in library section
8.2.9), which is yet another restatement of the same rules.
> This poor design precludes RnRS specifying read syntax for any
> EOF object.
Why do you believe it to be a poor design? It seems quite appropriate to
me for the EOF object not to be a datum value, for the same reason that it
should not be a character. You nowhere state what purpose such a read
syntax would serve. Do you wish to be able to use read to input a list of
EOF objects, for instance? What would you do with them?
John Cowan http://vrici.lojban.org/~cowan cowan@HIDDEN
Pour moi, les villes du Silmarillion ont plus de realite que Babylone.
--Christopher Tolkien, as interviewed by Le Monde
--0000000000004ff4790598502add
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Nov 27, 2019 at 2:45 AM Zefra=
m via Bug reports for GUILE, GNU's Ubiquitous Extension Language <<a=
href=3D"mailto:bug-guile@HIDDEN">bug-guile@HIDDEN</a>> wrote:<br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It'=
;s fairly obvious<br>
that it's a value that can't be returned by read-char, and therefor=
e is<br>
not itself a character, but that's quite a different matter.</blockquot=
e><div><br></div><div>On the contrary:=C2=A0 the EOF object is not a charac=
ter, but it *can* be returned by read-char .=C2=A0 Indeed it *is* returned =
by read-char just in case read-char is called after the last character of i=
ts input port has been read.=C2=A0 This makes it possible to distinguish be=
tween two cases: read-char returns a character if there are any in the inpu=
t port, and the EOF object if there are none.</div><div><br></div><div>By t=
he same token, read can return either a datum value or an EOF object.=C2=A0=
It returns a datum value if the remaining characters in its input port con=
stitute at least one datum (what R6RS calls an "external representatio=
n") or the EOF object if no characters are available, and raises an ex=
ception if the available characters do not constitute a datum.=C2=A0 An inp=
ut port containing just "(", for example, will not return an EOF =
object; it will raise an exception.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">The lack of<br>
s-expression representation actually comes from the entirely unobvious,<br>
and undocumented in Guile, use of the EOF value with the read function.<br>=
</blockquote><div><br></div><div>It's true that section 6.18.2 of the G=
uile 2.2.x manual is rather terse and does not document this behavior.=C2=
=A0 However, section 4.1 says that Guile is fully compliant with R5RS.=C2=
=A0 This means that it incorporates by reference the R5RS specification, an=
d in particular section 6.6.2, which restates at greater length the rules I=
have given above.=C2=A0 The definition of read in R6RS defers to the defin=
ition of get-datum=C2=A0(both are in library section 8.2.9), which is yet a=
nother restatement of the same rules.</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">This poor design precludes RnRS specifyi=
ng read syntax for any<br>
EOF object.</blockquote><div><br></div><div>Why do you believe it to be a p=
oor design?=C2=A0 It seems quite appropriate to me for the EOF object not t=
o be a datum value, for the same reason that it should not be a character.=
=C2=A0 You nowhere state what purpose such a read syntax would serve.=C2=A0=
Do you wish to be able to use read to input a list of EOF objects, for ins=
tance?=C2=A0 What would you do with them?</div><div><br></div><div><br></di=
v><div><br></div><div>John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=
=3D"http://vrici.lojban.org/~cowan">http://vrici.lojban.org/~cowan</a> =C2=
=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:cowan@HIDDEN">cowan@HIDDEN</a=
><br>Pour moi, les villes du Silmarillion ont plus de realite que Babylone.=
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --Christopher T=
olkien, as interviewed by Le Monde<br></div><div><br></div></div></div>
--0000000000004ff4790598502add--
bug-guile@HIDDEN:bug#38398; Package guile.
Full text available.Received: (at submit) by debbugs.gnu.org; 27 Nov 2019 07:44:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 27 02:44:48 2019 Received: from localhost ([127.0.0.1]:53386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iZs0G-0000M0-37 for submit <at> debbugs.gnu.org; Wed, 27 Nov 2019 02:44:48 -0500 Received: from lists.gnu.org ([209.51.188.17]:53139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <zefram@HIDDEN>) id 1iZs0F-0000Lt-6r for submit <at> debbugs.gnu.org; Wed, 27 Nov 2019 02:44:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35073) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <zefram@HIDDEN>) id 1iZs0D-0002zy-Ku for bug-guile@HIDDEN; Wed, 27 Nov 2019 02:44:46 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1iZs0C-0001q4-AR for bug-guile@HIDDEN; Wed, 27 Nov 2019 02:44:45 -0500 Received: from mail.fysh.org ([2001:41d0:d:20da::7]:51062 helo=river.fysh.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1iZs0B-0001oN-RS for bug-guile@HIDDEN; Wed, 27 Nov 2019 02:44:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fysh.org; s=20170316; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=wdnzjsYdA23gvh2f6Lr7ngMtti+H/pbKDktqnE1eiSw=; b=omQqKjkavJpfUVzvimygYIWRjr qV/quqAQO1CaWah0AxQSwOqbsbWSjzM7XZGbGuV0u3gFpWOlkn0K+BBwnNE5qFUN27bPb1oobZkNI 5tUrBzl8UndYan3zO4tiq1GpfSKAHz1MBzddVUEKNnhtUVbBIsVyHb5tlqMdJ+DPmB2c=; Received: from zefram by river.fysh.org with local (Exim 4.89 #1 (Debian)) id 1iZs04-0002sq-Mk; Wed, 27 Nov 2019 07:44:36 +0000 Date: Wed, 27 Nov 2019 07:44:36 +0000 From: Zefram <zefram@HIDDEN> To: bug-guile@HIDDEN Subject: non-obvious SCM_EOF_VAL rationale Message-ID: <20191127074436.e6gev22lgi2yqpkg@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2001:41d0:d:20da::7 X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) The part of the Guile manual on the representation of immediate objects says: # -- Macro: SCM SCM_EOF_VAL # The Scheme end-of-file value. It has no standard written # representation, for obvious reasons. I disagree with the manual: the reasons for the EOF value having no s-expression representation are not at all obvious. It's fairly obvious that it's a value that can't be returned by read-char, and therefore is not itself a character, but that's quite a different matter. The lack of s-expression representation actually comes from the entirely unobvious, and undocumented in Guile, use of the EOF value with the read function. In the RnRS series, the concept of an EOF object appears in R2RS, and remains essentially unchanged from there. (The only difference is that R6RS specifies that there is one EOF object, whereas all others allow for multiple EOF objects.) They all specify that if the read function encounters EOF then it will return an EOF object, and in order to support that usage they also specify that EOF objects can never be returned by read. This poor design precludes RnRS specifying read syntax for any EOF object. The relationship here is fairly obvious, but only once one is aware of this rather surprising use of EOF objects by read. The situation in Guile is more muddied. Because Guile supports the "#." syntax for read-time evaluation, it actually *is* possible for the read function to return an EOF object without having reached EOF: $ echo '#.(eof-object)' | guile-2.2 -c '(fluid-set! read-eval? #t) (use-modules (rnrs io simple)) (write (read)) (newline)' #<eof> This is technically a violation of RnRS, but I have no complaint about breaking such an onerous rule in these circumstances where it's necessitated only by such a poor design decision. Anyway, it means that the RnRS rationale for having no s-expression representation for the EOF object *doesn't apply* to Guile. There's also precedent, in "#nil", for Guile extending read syntax beyond RnRS for immediate objects. So it seems to me that you are quite free to invent some readable syntax such as "#eof" for the EOF object. So, to resolve this, firstly you should add to the documentation of the read function some text about its behaviour on EOF (on which it is currently silent). Perhaps also add some text about the ambiguity of read returning the EOF object. Then you should remove the ", for obvious reasons" part of the SCM_EOF_VAL documentation. After that you have a choice. You could leave the lack of s-expression representation unexplained. Alternatively you could attempt an actual explanation, which in the minimal form would be "so that without the use of the non-standard read-time-evaluation facility it can't be returned by the read function in non-end-of-file situations, which would cause an ambiguity". For Guile 2.4 you could instead add a read syntax for it and document that. -zefram
Zefram <zefram@HIDDEN>:bug-guile@HIDDEN.
Full text available.bug-guile@HIDDEN:bug#38398; Package guile.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.