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] |
> 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.