Re: Unrecognized \ sequences and Elisp

[Neil Jerram <neil@ossau.uklinux.net>]

>>>>> "Roland" == Roland Orre <orre@nada.kth.se> 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