From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Roland Orre Newsgroups: gmane.lisp.guile.devel Subject: Re: Unrecognized \ sequences and Elisp Date: Tue, 27 Jan 2004 13:50:14 +0100 Organization: Royal Institute of Technology Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <1075207814.23541.1113.camel@localhost> References: <1075174623.23547.960.camel@localhost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1075211410 17786 80.91.224.253 (27 Jan 2004 13:50:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Jan 2004 13:50:10 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 27 14:50:03 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 1AlTbP-0006fb-00 for ; Tue, 27 Jan 2004 14:50:03 +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 1AlTal-0007Ie-0I for guile-devel@m.gmane.org; Tue, 27 Jan 2004 08:49:23 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AlTXO-0006DM-2E for guile-devel@gnu.org; Tue, 27 Jan 2004 08:45:54 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AlTTl-0004xw-7P for guile-devel@gnu.org; Tue, 27 Jan 2004 08:42:40 -0500 Original-Received: from [130.237.222.202] (helo=smtp.nada.kth.se) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AlSko-0004ka-9L for guile-devel@gnu.org; Tue, 27 Jan 2004 07:55:42 -0500 Original-Received: from bari.bacon.su.se (bari.bacon.su.se [130.237.152.231]) (authenticated bits=0) by smtp.nada.kth.se (8.12.10/8.12.1) with ESMTP id i0RCtbRQ000410 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 27 Jan 2004 13:55:37 +0100 (MET) Original-To: Paul Jarc In-Reply-To: X-Mailer: Ximian Evolution 1.4.5 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:3320 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3320 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. OK, the question then is what to do with those escape sequences which are not understood? My view is that with a minimum of defined escape sequences as in R5RS you have a lot of freedom but not understood sequences should then not generate error, only be passed through. The follow up question then is of course, should "foo\(bar" pass as "foo(bar" or "foo\(bar"? >>From my view it it sounds quite wrong to have to change the actual sequences now occuring in elisp to fit guile. This is the wrong way around, as I considier that guile should be a general platform. > > I consider the reason for escape sequences in strings is to be able > > to express a " within a string, i.e. to be able to express a > > character that we would otherwise not be able to put in the string. > They're also useful for representing characters that would be > difficult to work with literally - control characters, etc. Yes, I agree to a certain extent, but this can be handled other ways, (string-append "foo" (string #\nl) "bar") is of course a lot uglier than "foo\nbar" but in ordinary code you don't need this very often. This facility is mostly useful in format strings, and I consider it is better to be kept there. One way to view the question is, do we want the strings to actually contain what control characters etc we feed into them, or do we only want them to be printed in a certain way? When I (define foobar "foo\nbar") do I want it to really evaluate to "foo bar" or do I just want it to print a newline when passed through a certain write command? For my own I consider the latter the more useful approach. > > I consider that it is better to have routines like read-ansi-string > > and write-ansi-string, which was previously suggested, > > Do you have a reference? I don't know what those are intended to do, > but it doesn't sound like the same job that escape sequences do. Sorry, this was no deep thinking, I just found some statements about this in the mail archives: http://mail.gnu.org/archive/html/guile-devel/2001-05/msg00465.html > > general interpretation of escape sequences within strings will > > affect the general handling of strings in different applications. > > Well, if we see the two characters \( in the middle of a string, then > the program is not portable, and we have to decide on our own what to > do about it. Treating it like plain ( eliminates the possibility of > future extensions, so now Guile has been changed to throw an error - > i.e., it refuses to interpret this escape sequence at all. Isn't that > what you want? Well, emacs regexp expressions uses e.g \( and \| where guile regexp uses only ( and |. I see the whole issue as tricky. Even Aubrey Jaffer's scm and emacs lisp interpret e.g. "foo\nbar" as "foo bar" I think I would have preferred if escape sequences in read/write of strings in general never had become an issue, as these mostly have to do with formatting, which should be kept separate. My view is somewhat that when escape sequences are used in strings, then they should work so that any character after the escape character is feed into the string, which makes \\ and \" meaningful, but this then create insane strings like "\\(foo\\|bar\\)" if the escape character itself is used by the application. I'm stuck, I can't find a good solution to this, but my worry is that more complex handling of escape sequences in strings will cause more problems and extra work than it solves. Best regards Roland _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel