From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Zefram via "Bug reports for GUILE, GNU's Ubiquitous Extension Language" Newsgroups: gmane.lisp.guile.bugs Subject: bug#38398: non-obvious SCM_EOF_VAL rationale Date: Wed, 27 Nov 2019 07:44:36 +0000 Message-ID: <20191127074436.e6gev22lgi2yqpkg@fysh.org> Reply-To: Zefram Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="48672"; mail-complaints-to="usenet@blaine.gmane.org" To: 38398@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed Nov 27 08:45:12 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 1iZs0e-000CTk-Cy for guile-bugs@m.gmane.org; Wed, 27 Nov 2019 08:45:12 +0100 Original-Received: from localhost ([::1]:35506 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZs0d-00030X-6M for guile-bugs@m.gmane.org; Wed, 27 Nov 2019 02:45:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35105) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZs0V-00030R-KK for bug-guile@gnu.org; Wed, 27 Nov 2019 02:45:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZs0U-00020a-Fn for bug-guile@gnu.org; Wed, 27 Nov 2019 02:45:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47413) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iZs0U-00020S-Bn for bug-guile@gnu.org; Wed, 27 Nov 2019 02:45:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iZs0U-0000Mp-9j for bug-guile@gnu.org; Wed, 27 Nov 2019 02:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Zefram Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 27 Nov 2019 07:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 38398 X-GNU-PR-Package: guile X-Debbugs-Original-To: bug-guile@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.15748406881368 (code B ref -1); Wed, 27 Nov 2019 07:45:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 27 Nov 2019 07:44:48 +0000 Original-Received: from localhost ([127.0.0.1]:53386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZs0G-0000M0-37 for submit@debbugs.gnu.org; Wed, 27 Nov 2019 02:44:48 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:53139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZs0F-0000Lt-6r for submit@debbugs.gnu.org; Wed, 27 Nov 2019 02:44:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35073) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZs0D-0002zy-Ku for bug-guile@gnu.org; Wed, 27 Nov 2019 02:44:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZs0C-0001q4-AR for bug-guile@gnu.org; Wed, 27 Nov 2019 02:44:45 -0500 Original-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 ) id 1iZs0B-0001oN-RS for bug-guile@gnu.org; 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=; Original-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 Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:9472 Archived-At: 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)' # 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