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. 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: GROUP - exists in SRFI-49 (backward compatibility yeah!) - already implemented - current fallback position SPLICE - 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). SPLIT - gives good syntax for Arc 'if and CL keywords (and can only be replaced with SPLICE). - subsumes both GROUP and SPLICE. ENLIST - 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: GROUP - can be subsumed into either ENLIST or SPLIT SPLICE - 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 SPLIT - 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 ENLIST - 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. Sincerely, AmkG ------------------------------------------------------------------------------ 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
