From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: John Cowan Newsgroups: gmane.lisp.guile.bugs Subject: bug#38398: non-obvious SCM_EOF_VAL rationale Date: Wed, 27 Nov 2019 03:55:47 -0500 Message-ID: References: <20191127074436.e6gev22lgi2yqpkg@fysh.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004ff4790598502add" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="83312"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38398@debbugs.gnu.org To: Zefram Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed Nov 27 09:57:14 2019 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iZt8K-000LSg-G9 for guile-bugs@m.gmane.org; Wed, 27 Nov 2019 09:57:12 +0100 Original-Received: from localhost ([::1]:35922 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZt8I-0001Os-92 for guile-bugs@m.gmane.org; Wed, 27 Nov 2019 03:57:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48409) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZt8C-0001OR-2T for bug-guile@gnu.org; Wed, 27 Nov 2019 03:57:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZt8A-0005HO-DJ for bug-guile@gnu.org; Wed, 27 Nov 2019 03:57:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47450) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iZt8A-0005HB-1Q for bug-guile@gnu.org; Wed, 27 Nov 2019 03:57:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iZt89-0002De-Vl for bug-guile@gnu.org; Wed, 27 Nov 2019 03:57:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: John Cowan Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 27 Nov 2019 08:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38398 X-GNU-PR-Package: guile Original-Received: via spool by 38398-submit@debbugs.gnu.org id=B38398.15748449678450 (code B ref 38398); Wed, 27 Nov 2019 08:57:01 +0000 Original-Received: (at 38398) by debbugs.gnu.org; 27 Nov 2019 08:56:07 +0000 Original-Received: from localhost ([127.0.0.1]:53421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZt7G-0002CE-RZ for submit@debbugs.gnu.org; Wed, 27 Nov 2019 03:56:07 -0500 Original-Received: from mail-qk1-f169.google.com ([209.85.222.169]:33065) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZt7D-0002BY-Vp for 38398@debbugs.gnu.org; Wed, 27 Nov 2019 03:56:05 -0500 Original-Received: by mail-qk1-f169.google.com with SMTP id c124so14383509qkg.0 for <38398@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) In-Reply-To: <20191127074436.e6gev22lgi2yqpkg@fysh.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:9473 Archived-At: --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 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@ccil.org 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


=
On Wed, Nov 27, 2019 at 2:45 AM Zefra= m via Bug reports for GUILE, GNU's Ubiquitous Extension Language <bug-guile@gnu.org> wrote:
=C2=A0
It'= ;s fairly obvious
that it's a value that can't be returned by read-char, and therefor= e is
not itself a character, but that's quite a different matter.

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.

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.
=C2=A0
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 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.
=C2=A0
This poor design precludes RnRS specifyi= ng read syntax for any
EOF object.

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?

--0000000000004ff4790598502add--