Per Bothner <per_at_bothner.com> writes:
> This change may be viewed as conflicting with:
> \<space> space "useful for terminating the previous escape sequence
> before continuing with whitespace"
> However, there is no problem, since \<space> is useless
It allows to "begin a string literal on one line\
\ and continue on the next line with a significant space".
Granted, in this case it would be simpler to move the space to the end
of the previous line. And generally this is a nice solution, but it
might not be enough in all cases, e.g. when there are many spaces and
one doesn't want to keep all of them on the previous line.
Haskell uses \<intraline whitespace><linefeed><intraline whitespace>\
I don't like these closing backslashes on the next line. When they
happen to be placed before a lowercase letter, they don't form an
escape sequence together with that letter despite the appearance which
suggests otherwise. This also caused troubles when Haskell files were
passed through a C preprocessor (which is arguably a silly thing to do
and can't work in all cases anyway, but it worked most of the time,
and this was one of exceptions).
For my language Kogut, which uses the same
\<intraline whitespace><linefeed><intraline whitespace> rule, I first
used \s for a space for this reason, then changed it to \<space>
forgetting that this was the reason, then changed it back to \s when
I realized that they conflict and that supporting both would require
arbitrarily long lookahead in the lexer.
It's possible to state that \<space> is valid only immediately after
\<intraline whitespace><linefeed><intraline whitespace> and that two
such ignored linefeeds can't be put next to each other. This yields
prettier code in most cases, but rules become ugly, with an ambiguity
which is then resolved.
--
__("< Marcin Kowalczyk
\__/ qrczak_at_knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Received on Tue Sep 19 2006 - 04:34:35 UTC