All right all right, let's use this thread to discuss GROUP, SPLICE,

Let's call this DEBATE POINT 1, for reasons that are not readily apparent.

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

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.

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.

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.

Note that the various concepts are NOT necessarily incompatible with
each other - we could in theory assign different markers for ALL of
them, but we would really like to reduce the number of existing rules.

Pros of each:

- exists in SRFI-49 (backward compatibility yeah!)
- already implemented - current fallback position

- gives good syntax for Arc 'if and CL keywords (and can only be
replaced with SPLIT).
- BACKSLASH symbol at the end (as originally proposed) is compatible
with other language's habits (consider sh and C).

- gives good syntax for Arc 'if and CL keywords (and can only be
replaced with SPLICE).
- subsumes both GROUP and SPLICE.

- arguably nearer to most user's intuition when encountering the
"group" keyword in SRFI-49
- reduces vertical depth especially for let, the bane of
indentation-based syntax.
- subsumes GROUP

Cons of each:

- can be subsumed into either ENLIST or SPLIT

- arguably complicated rule
- the BACKSLASH-at-the-end rule is arguably unrelated to the other two
rules, and is a potential source of inconsistency.
- not implemented

- Using BACKSLASH for this rule is incompatible with other language's habits.
- Using PERIOD for this rule is incompatible arguably with general Lisp syntax.
- If we can't use either BACKSLASH or PERIOD, we can't use anything
for this meaning!
- not implemented

- Not fully specified, possibly complicated to implement.
- not implemented


My position is:

1.  NO to GROUP and SPLICE

2.  YES to SPLIT, and use \ for it, and ignore other language's habit
of using it to mean "continue to next line"

3.  YES to ENLIST, and use ~ for it, and really start to crystallize
what exactly is meant with ~ in various contexts.

Pros to my position:

1.  We get good syntax for Arc 'if and CL keywords.  This I think is
the most important point.  I feel that I cannot support a position
that cannot similarly give a good syntax for Arc 'if and CL :keywords,
and is my one non-negotiable.

2.  Reduces the rules by removing the GROUP rule, making it a part of
the overarching SPLIT rule.

3.  Allows shortening of let syntax slightly, by use of ENLIST.

4.  Allows us to retain "." as "indentation whitespace" LOLrule.

Cons to my position:

1.  Both SPLIT-by-itself and ENLIST-by-itself, followed by a line that
is more indented, mean exactly the same thing.  This is arguably Not a
Good Thing, as there is now more than one way to express something,
neither being a truly "preferred" way.

2.  ENLIST is not yet fully specified, and its full
specification/implementation might be more complex than what our
current thinking suggests.

3.  Using "\" for SPLIT is not compatible with most other language's
usage, especially when it occurs at end-of-line.


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 
Readable-discuss mailing list

Reply via email to