I've tried to write the potential rules for "\ " more clearly, yet simply.
They are here:

Current text:
When doing indentation processing, if the first character of
a form is "\" followed by whitespace:
* If it's the last character of the line (other than 0 or more spaces/tabs),
then the newline is considered a space, and the next line's indentation
is irrelevant. This continues the line.
(Note that comments cannot follow, because that would be confusing.)
* If it's between items on a line, it's interpreted as
a line break to the same indentation level.
* Otherwise, if it's at the beginning of a line (after 0+ spaces/tabs), 
it's ignored - but the first non-whitespace character's indentation level is 

I'm really beginning to warm to this one.  Most of the time you don't
need it, but there are definitely some common use cases where it's helpful.
And if you don't use it, it doesn't make things harder.

Also, I think I should modify the interpretation of unprefixed [...].
Basically, unprefixed [...] should mean "whatever they mean to the underlying 
For Scheme, [...] should be the same as (...) because that's what
they mean in R6.  That'll make sweet-expressions
easier to use with Arc and other Lisps that define [...] differently.
I'll probably keep prefixed [...] with its (bracketaccess ...) meaning simply
because it's impractical to "add" anything later, but it's not significantly 
In any case, indentation processing is disabled inside [...].

--- David A. Wheeler

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Readable-discuss mailing list

Reply via email to