This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A useful syntax for regexps and other things


> I think it's good for Guile to support a "pure R4RS" mode, for people
> who want to be able to write portable code.  But I'm not sure it's
> important that pure R4RS be the default.
> 

OK, I can accept that, but I wonder why you addressed the comment to
me, as I have not said anything that seems to me to conflict with it.

Given the "Subject:" line, I conjecture that you may have
misunderstood the logical structure of my last post.  It consisted of
two orthogonal parts, related only in that they both had to do with
string syntax.  The first part (short) was an expression of misgivings
about the proposed syntax to substitute an arbitrary character for the
double quote as a string delimiter.  I did not go into reasons, but
"not R4RS" was not one of the big reasons.  In fact, the second part
was a proposal to extend R4RS with with some syntax to make it
possible to indent a multi-line string without screwing it up.  This
proposal must stand or fall on its own merits, it is not intended as
an alternative to the "arbitrary quote character" proposal.

I said what I had to say about the "indentable string" proposal, let me
say a bit more about the arbitrary quote.

-----------
Changing the quote character to something else for the duration of one
string seems wrong, because you still have a character that can't be
put in the string, it's just a different one.  After reading double
quoted strings for a while, you get used to the convention and learn
not to put quotes into the middle of a string without escaping them.
If the quote can be changed, you might find that fixing a mispelling
in the middle of some English text radically changes the lexical structure
of the program.

Anti-proposal: Let's not write

  (string-append #<s Unfixable "miztakes" and unreadable code"s)

-----------
There is more merit in the proposal for "here strings".  With these you
can write a block of text without any forbidden characters.  But #<< is
the wrong introduction.  I understand why it might be chosen based upon
the shell, but in the shell < means stdin redirection and > means stdout.
We are making string syntax, not redirection, and there is no #>>.  It is
perverse to use an opening bracket with no corresponding close bracket.

Proposal: (display #"PARAGRAPH-QUOTE
After #" <word> <newline>, all following characters are part of a
single string, without translation or escape characters until the next
occurrence of <newline> #" <word>.  The <newline> at the start is not
part of the string, but the <newline> before the closing #" is.  The
<word> should consist entirely of letters, digits, and extended alpha-
betic characters.  There should be no whitespace between #" and <word>.
#"PARAGRAPH-QUOTE)
is an expression that displays six lines on the current output port.

-- 
     --Keith

This mail message sent by GNU emacs and Linux.
Power to the people. Linux is here.
Food, Shelter, Source code.