Okay, let's recap this topic.
1. almkglor's original proposal:
At start-of-line, the "." character is treated as a space character
until the first non-tab, non-space, non-"." character. This means
that "." can be used as indentation, and is equivalent to space for
purposes of indentation matching.
2. dwheeler's current implemented proposal:
The characters tab, space, and "." are indentation characters; "."
loses the whitespace meaning outside of indentation. For purposes of
indentation matching "." in the current line must match a "." in the
indentation of the previous line.
3. dwheeler's initial "." proposal
Indentation may start with either tab, space, or any number of ".",
and the rest of indentation is either tabs or spaces. For purposes of
indentation matching "." in the current line must match a "." in the
indentation of the previous line.
4. dwheeler's pair-characters proposal
The characters tab and space are indentation characters, and the "."
character, if followed by a tab or space, is also an indentation
character (if followed by a newline, it's not an indentation
character). The "." character loses its whitespace meaning outside of
indentation. For purposes of indentation matching "." in the current
line must match a "." in the indentation of the previous line.
--
My position is #1. I could accept #2 if that's what the consensus is.
1. I like it because we can draw arbitrary graphics using "."
characters in the indentation area. This is useful for highlighting
sections of code.
2. I could accept #2 since most of the graphics I'm going to draw are
simple vertical lines showing the indentation level of long cond
clauses and what-not. The loss of drawing arbitrary graphics is minor
to consensus. I'd still prefer #1 though.
3. I can't accept #3 since it only allows drawing a vertical line at
the very left edge, or possibly a bar graph limited to the indentation
level, neither of which are useful.
4. I can't accept #4 because I'm not assured that it is easy to
implement given a one-character lookahead implementation (Scheme). I
think that it is a significant implementation burden, in order to
support what I consider to be minor advantages.
In particular, the ... symbol is only majorly used in Scheme's
syntax-rules. Now, the idiom in using ... looks like this:
(syntax-rules ()
((begin x
body ...)
(let ((v x))
(begin
body ...))
blah blah
If we are to use indentation, and try to match the appearance as
closely as possible:
syntax-rules ()
. \
. . begin x
. . body \ ...
. . \ let ((v x))
. . . begin
. . . body \ ...
blah blah
Note that we need to "escape" the ..., as otherwise it will be paired
with body, resulting in (body ...) instead of two separate elements
body and ...
So I think requiring \ for . and .. an ... are fine to me.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
