unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Roland Orre <orre@nada.kth.se>
Cc: guile-devel@gnu.org
Subject: Re:  Unrecognized \ sequences and Elisp
Date: Tue, 27 Jan 2004 13:50:14 +0100	[thread overview]
Message-ID: <1075207814.23541.1113.camel@localhost> (raw)
In-Reply-To: <m3d695ep8y.fsf@multivac.cwru.edu>

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


  reply	other threads:[~2004-01-27 12:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-27  3:37 Fwd: Re: Unrecognized \ sequences and Elisp Roland Orre
2004-01-27  9:04 ` Paul Jarc
2004-01-27 12:50   ` Roland Orre [this message]
2004-01-27 16:26     ` tomas
2004-01-27 17:43     ` Stephen Compall
2004-01-28 17:03     ` Neil Jerram
2004-02-08 19:16       ` Neil Jerram
2004-02-08 22:06         ` Marius Vollmer
2004-02-10 19:27           ` Neil Jerram
2004-02-18 21:10             ` Marius Vollmer
  -- strict thread matches above, loose matches on Subject: below --
2004-01-26 23:26 Neil Jerram
2004-01-27  2:45 ` Paul Jarc
2004-01-27  6:44   ` Stephen Compall
2004-01-27  8:55     ` Paul Jarc
2004-01-28 16:32       ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1075207814.23541.1113.camel@localhost \
    --to=orre@nada.kth.se \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).