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 12:05:34 +0000 Message-ID: <20191127120534.i6okeasqcaodpae6@fysh.org> References: <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="89471"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38398@debbugs.gnu.org To: John Cowan Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed Nov 27 13:06: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 1iZw5D-000N2R-JM for guile-bugs@m.gmane.org; Wed, 27 Nov 2019 13:06:11 +0100 Original-Received: from localhost ([::1]:37504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZw5C-00016V-7w for guile-bugs@m.gmane.org; Wed, 27 Nov 2019 07:06:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52163) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZw56-00015Y-Fu for bug-guile@gnu.org; Wed, 27 Nov 2019 07:06:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZw55-0005oj-2v for bug-guile@gnu.org; Wed, 27 Nov 2019 07:06:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47586) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iZw54-0005oA-Ld for bug-guile@gnu.org; Wed, 27 Nov 2019 07:06:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iZw54-0000uD-HP for bug-guile@gnu.org; Wed, 27 Nov 2019 07:06: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 12:06:02 +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.15748563413426 (code B ref 38398); Wed, 27 Nov 2019 12:06:02 +0000 Original-Received: (at 38398) by debbugs.gnu.org; 27 Nov 2019 12:05:41 +0000 Original-Received: from localhost ([127.0.0.1]:53552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZw4j-0000tC-2c for submit@debbugs.gnu.org; Wed, 27 Nov 2019 07:05:41 -0500 Original-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 ) id 1iZw4h-0000t2-8l for 38398@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=; Original-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 Content-Disposition: inline In-Reply-To: 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:9475 Archived-At: 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