Hi Alan,
At Wed, 11 Jul 2012 17:28:43 +0800,
Alan Manuel Gloria wrote:
>
> All right all right, let's use this thread to discuss GROUP, SPLICE,
> SPLIT, and ENLIST.
>
> Let's call this DEBATE POINT 1, for reasons that are not readily apparent.
I tried to follow your reasoning, but I did not get a concrete image
of the different points. I think I missed code examples…
> GROUP - the original SRFI-49 rule. The GROUP marker is "invisible"
> when at the start of the line, and is removed, except for its effect
> on indentation - the indentation of that line is still the column
> where the GROUP marker is. The net effect is that if GROUP is on a
> line by itself followed by a line that is more indented, an extra open
> parenthesis appears. Otherwise, GROUP does *not* cause an increase in
> nestedness. I don't remember well, but it was not explicitly
> specified what would happen if group occurs on a line by itself and is
> followed by a line on the *same* indent level - presumably it inserts
> the empty list. The original GROUP marker was the symbol "group".
With . as group marker:
let
.
a b
c a
(let
((a b))
(c a)
> SPLICE - a proposed addition to the sweet-expressions 0.2 spec. The
> SPLICE marker acts differently based on its location (1) at the end of
> a line, the next line's indentation is ignored and it is treated as a
> continuation of the previous line - i.e. "spliced" (2) at the start of
> a line, it is simply ignored (3) in the middle of the line, it is
> treated as a newline followed by an indentation to a column equal to
> the current line's indentation. It is not explicitly specified, but
> implied that if the SPLICE is on a line by itself, the "end-of-line"
> meaning is invoked rather than "start-of-line". Originally proposed
> with "\" being the SPLICE marker.
defun \
a ()
\ b \ c
(defun a ()
(b) (c))
> SPLIT - a proposed modification of SPLICE rules that allows
> unification with existing GROUP rules. The "end-of-line" meaning is
> removed completely, and is interpreted in the same manner as the
> "inline" rule. SPLIT at the start of the line is ignored (the same
> meaning as SPLICE-at-the-start). SPLIT-by-itself invokes the
> "start-of-line" meaning. Variously proposed with "\" or "." being the
> SPLIT marker.
defun a ()
. b .
c
defun a ()
\ b \
c
(defun a ()
(b) (c))
let
.
??? → I don’t understand what it means on its own.
> ENLIST - a proposed modification of GROUP rules that (probably?) gives
> better intuition to the meaning. ENLIST at the start of a line always
> increases the nestedness of the rest of the line, and if the
> succeeding line(s) are more indented, will have the same nestedness as
> the first line. Presumably, multiple ENLIST at the start of the line
> also further increase the nestedness, and presumably an "empty" ENLIST
> line (i.e. a line composed only of ENLIST markers) will simply
> increase nestedness of the succeeding line if it is more indented than
> the ENLIST line. Also presumably, an ENLIST in the middle of a line
> would allow succeeding lines to have multiple, reducing indentation
> levels as long as they more indented than the ENLIST line, although no
> actual concrete specification exists for this behavior. Originally
> proposed as a reinterpretation of GROUP, renamed in order to separate
> its concepts from GROUP and give better discussion.
let
\
a b
defun c () \ d
(let
((a b))
(defun c ()
(d)))
Did I understand that correctly?
I cannot comment on the pros and cons without being sure that I really
understand the rules…
Best wishes,
Arne
------------------------------------------------------------------------------
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
