Re: Unrecognized \ sequences and Elisp

[Roland Orre <orre@nada.kth.se>]

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