From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: Unrecognized \ sequences and Elisp Date: 28 Jan 2004 17:03:35 +0000 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <1075174623.23547.960.camel@localhost> <1075207814.23541.1113.camel@localhost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1075310470 7641 80.91.224.253 (28 Jan 2004 17:21:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2004 17:21:10 +0000 (UTC) Cc: Paul Jarc , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jan 28 18:20:51 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AltMw-0007Y7-00 for ; Wed, 28 Jan 2004 18:20:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AltLB-0004Va-UW for guile-devel@m.gmane.org; Wed, 28 Jan 2004 12:19:01 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AltKs-0004PO-5H for guile-devel@gnu.org; Wed, 28 Jan 2004 12:18:42 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AltKI-0004At-UH for guile-devel@gnu.org; Wed, 28 Jan 2004 12:18:38 -0500 Original-Received: from [80.84.72.14] (helo=mail2.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AltHy-0003Rq-St for guile-devel@gnu.org; Wed, 28 Jan 2004 12:15:43 -0500 Original-Received: from localhost (s4.uklinux.net [127.0.0.1]) by mail2.uklinux.net (Postfix) with ESMTP id 4A32B409FA7; Wed, 28 Jan 2004 17:15:31 +0000 (UTC) Original-Received: from mail2.uklinux.net ([127.0.0.1]) by localhost (s4.uklinux.net [127.0.0.1:10024]) (amavisd-new) with ESMTP id 06145-08; Wed, 28 Jan 2004 17:14:57 +0000 (GMT) Original-Received: from laruns.ossau.uklinux.net (unknown [213.78.87.229]) by mail2.uklinux.net (Postfix) with ESMTP id 4512D40A03E; Wed, 28 Jan 2004 17:08:04 +0000 (UTC) Original-Received: from laruns.ossau.uklinux.net.ossau.uklinux.net (localhost [127.0.0.1]) by laruns.ossau.uklinux.net (Postfix on SuSE Linux 7.2 (i386)) with ESMTP id 268E5DC4D6; Wed, 28 Jan 2004 17:03:36 +0000 (GMT) Original-To: Roland Orre In-Reply-To: <1075207814.23541.1113.camel@localhost> Original-Lines: 86 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 X-Virus-Scanned: by amavisd-new X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 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 Xref: main.gmane.org gmane.lisp.guile.devel:3328 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3328 >>>>> "Roland" == Roland Orre writes: Roland> On Tue, 2004-01-27 at 10:04, Paul Jarc wrote: >> Then portable programs cannot use other escape sequences, which means >> that implementations can invent meanings for other escape sequences >> without breaking portable programs. Roland> OK, the question then is what to do with those escape sequences which Roland> are not understood? My view is that with a minimum of defined escape Roland> sequences as in R5RS you have a lot of freedom but not understood Roland> sequences should then not generate error, only be passed through. Roland> The follow up question then is of course, should "foo\(bar" pass Roland> as "foo(bar" or "foo\(bar"? The position as regards portable Scheme programs is clear: a portable R5RS program should not use anything that is not defined by R5RS, which includes \(. If a supposedly portable program accidentally uses something non-portable, it is usually better to get a clearly signaled error, than (silently) some behavior which may not be what was intended. Guile by default goes a long way beyond R5RS, so there is no good portability argument against allowing \( in Guile at all. If there was, then an exactly analogous argument could be made against Guile's many non-R5RS primitives that are provided in the default environment: it could be argued that Guile should signal an error if any non-R5RS procedure was assumed to exist. Guile also provides a strict R5RS mode, though, where the last clause is true. In this mode, use of \( should signal an error. Finally, there is the fact that \( per se isn't actually useful, other than for handling existing Elisp code. This tends to suggest that \( should not be on by default, even outside strict R5RS mode. Therefore I propose to reinstate \( support, but subject to the SCM_ENABLE_ELISP #define and a runtime read option. I also propose to do the same for any other bits of Elisp read syntax that I need. (Currently this is [ ] for vectors and \).) This means that to make \( etc. work, you'd need both to configure with --enable-elisp, and to set a read option using (read-enable 'escaped-parentheses). Does this sound OK? Roland> Yes, I agree to a certain extent, but this can be handled other ways, Roland> (string-append "foo" (string #\nl) "bar") Roland> is of course a lot uglier than "foo\nbar" but in ordinary code you Roland> don't need this very often. This facility is mostly useful in Roland> format strings, and I consider it is better to be kept there. Roland> One way to view the question is, do we want the strings to actually Roland> contain what control characters etc we feed into them, or do we Roland> only want them to be printed in a certain way? Roland> When I (define foobar "foo\nbar") do I want it to really evaluate to Roland> "foo Roland> bar" Roland> or do I just want it to print a newline when passed through a certain Roland> write command? For my own I consider the latter the more useful Roland> approach. What a fascinating idea! I'd never thought of things like this before. However, I agree with others' replies that it would be odd for Guile to differ in its interpretation here from most other programming languages. I also think it would be counter intuitive to be able to form a string by concatenating "foo\" and "nbar", and then for this string to print with a newline in the middle of it. I also worry that your approach would affect the ability to repeatedly write and reread strings (the intention being that you get an equivalent string back, of course). So in summary, I'm afraid I don't think we should switch to your alternative. Roland> Well, emacs regexp expressions uses e.g \( and \| where guile regexp Roland> uses only ( and |. Just to avert any possible confusion here, note that this difference is one level higher than the current string syntax issue. As strings, these are: "\\(" and "\\|" in emacs "(" and "|" in guile. Regards, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel