From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Fix reader options for R6RS `get-datum' Date: Sun, 16 Dec 2012 17:12:22 -0500 Message-ID: <87wqwh3aux.fsf@tines.lan> References: <1355057247-17885-1-git-send-email-a.rottmann@gmx.at> <87boe09w3q.fsf@tines.lan> <87txrr0xes.fsf@delenn.home.rotty.xx.vu> <874njq96iw.fsf@tines.lan> <87k3sljp1r.fsf@delenn.home.rotty.xx.vu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1355695969 1933 80.91.229.3 (16 Dec 2012 22:12:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Dec 2012 22:12:49 +0000 (UTC) Cc: guile-devel@gnu.org To: Andreas Rottmann Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Dec 16 23:13:00 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TkMS9-0004xF-8N for guile-devel@m.gmane.org; Sun, 16 Dec 2012 23:12:57 +0100 Original-Received: from localhost ([::1]:40949 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkMRv-0007r5-Ib for guile-devel@m.gmane.org; Sun, 16 Dec 2012 17:12:43 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkMRt-0007r0-3d for guile-devel@gnu.org; Sun, 16 Dec 2012 17:12:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkMRr-0007UA-MI for guile-devel@gnu.org; Sun, 16 Dec 2012 17:12:41 -0500 Original-Received: from world.peace.net ([96.39.62.75]:54384) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkMRr-0007U0-Gd for guile-devel@gnu.org; Sun, 16 Dec 2012 17:12:39 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TkMRi-00011E-J6; Sun, 16 Dec 2012 17:12:30 -0500 In-Reply-To: <87k3sljp1r.fsf@delenn.home.rotty.xx.vu> (Andreas Rottmann's message of "Fri, 14 Dec 2012 04:22:24 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15349 Archived-At: Andreas Rottmann writes: > Mark H Weaver writes: > >> Section 8.3 defines 'read' as follows: >> >> Reads an external representation from textual-input-port and returns >> the datum it represents. The read procedure operates in the same way >> as get-datum, see section 8.2.9. >> >> I believe this last sentence clearly confirms my belief that 'read' and >> 'get-datum' should recognize the same syntax. >> > Well yes, R6RS `read' and R6RS `get-datum' need to understand the same > syntax, but I thought you were talking about Guile `read' and R6RS > `get-datum'. Ah, so you want R6RS 'read' to be different than Guile 'read'. I think this would be a mistake. I'd like to allow coherent systems to be built from a mixture of R6RS code, R7RS code, native Guile code, etc. With this in mind, I think it would be terribly confusing for users (and not particularly sensible) for the notation recognized by 'read' to depend upon whether the code that happens to call 'read' is in an R6RS library or a Guile module. For example, the code that calls 'read' when compiling source files happens to be in a Guile module. What does that have to do with the language being read? Nothing. > Yup, R6RS `read' needs to be implemented in terms of `get-datum', not > only because of reader options, but also because of the required > exception behavior. This is how it's done already -- see > modules/rnrs/io/simple.scm. I thought we agreed on IRC that this is an unworkable approach to supporting R6RS exceptions in Guile. That path leads to a future where there are two variants of every primitive procedure that might throw exceptions. It also means duplicating every VM instruction that might throw exceptions. Those facts alone would be bad enough, but it gets worse. In a program composed of a mixture of R6RS and native Guile code, an R6RS exception handler should be able to properly catch an error that happened within native Guile code, and vice versa. That won't work with this approach of throwing R6RS-style exceptions from within R6RS primitives and Guile-style exceptions within Guile primitives. IMO, to create a coherent system that allows mixing of code, we need a single unified exception system that is sufficiently fine-grained (and provides enough information) to satisfy the needs of both R6RS exception handlers and legacy Guile exception handlers. At any given time, there might be exception handlers installed by both Guile 'catch' and R6RS 'guard'. The code that throws an exception has no way of knowing which kind of exception handler will catch it. Therefore, the conversion to native R6RS conditions needs to happen within the exception handler. Does that make sense? I thought we discussed this on IRC and agreed on this general approach. >> On the flip side, if someone has enabled SRFI-105 curly-infix >> expressions, or any other reader extension that does not conflict with >> standard R6RS notation, then both 'get-datum' and 'read' should honor >> that setting. >> >> Does that make sense? >> > It does, and I think this is also what my patch implements, if I > understood both the code and your words correctly :-). To make this more concrete, let's consider two of the reader options that you'd apparently like to override within R6RS code: *** Case insensitivity (you would force case-sensitive mode in R6RS): R6RS appendix B specifies the following optional reader directives: #!fold-case #!no-fold-case and Guile 2.0.7 now supports this. Your patch would break this when 'read' is used within R6RS code. Furthermore, it would break in a strange way: #!fold-case or #!no-fold-case would take affect for the immediately following datum (or the containing datum if the directive is found within a list), but then the reader would revert to case-sensitive mode for subsequent datums. *** Keyword style (you would disallow this option in R6RS): While it is true that ':' is one of the "extended alphabetic characters" allowed in identifiers (and therefore the standard requires that :foo be read as a normal symbol), this has _always_ been the case in every Scheme standard since at least the R2RS. Nonetheless, some users want a more convenient syntax for keywords, hence we have this reader option. It is off by default, but some users prefer to have it on. I don't see why this setting should be ignored if the code that calls 'read' happens to be in an R6RS library. Furthermore, I intend to add another reader directive to set the keyword option. If you override this option, it will break in the same manner as for #!fold-case as described above. I have more to say about this issue, but this is enough for one email :) Thoughts? Regards, Mark