On 7/9/12, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> The special chars that look most promising to me as single chars:
>> \ = often means "continue on next line" when at eol in other languages
> This is one I've been using, and as noted earlier, it already has a meaning
> to many readers.
>
>> ~ = mostly unused except in Arc, where ~foo means "the function foo
>> with its output notted" and ~ means "the not function"; otherwise
>> valid function name
>> ^ = otherwise valid function name (superscript? even infix
>> exponentiation or XOR operator: {a ^ b})
>
> They don't have to be single characters, though. The current "group" marker
> is already multiple characters. Plausible special abbreviations could
> include:
> ~~
> ^^
> --
I'm opposed to multi-char syntax markers mostly because of the
one-character lookahead. Current SRFI-49-based implementation handles
'group OK, but at the price of not following the structure of its
spec. This allowed spec bugs to get through. So: I'm more open to
single-char syntax as it is much easier to write the implementation to
be closer to the spec.
>
> Since "." is unlikely to occur at the beginning of a line, that's plausible
> as a group marker, but as I described earlier I don't think we should use it
> in the middle (e.g., for splits).
.-by-itself also precludes .-as-indent, and I feel that .-as-indent is
actually more useful, even though you were trolling when you proposed
that. As I mentioned before, proper design of the SPLICE rules allows
SPLICE = GROUP, so we can free up "." to be indent by selecting
another character for SPLICE.
>
> Maybe we can divide this discussion into two areas:
> 1. Which symbols can we use for special operations, e.g., ~
~
\
^
@
.
> 2. What semantics should we use. Perhaps we can use placeholders SYMBOL1,
> SYMBOL2, SYMBOL3 when we don't care.
We should probably rename SPLICE, since at this point it's not
*really* SPLICE anymore. From my point of view, your original thought
seems to have been "\-at-eol removes indentation from succeeding
line", which gives the word "SPLICE" the correct meaning, but you then
realized that it would not be sufficient to clearly express the Arc
'if and CL keywords if the sub-expression involved wants something
complicated. You then overloaded "\" to have special meanings at the
start and middle of the line, which aren't actually "splice" per se
(and are more of "end the expression at this point").
I then argued for the removal of the SPLICE-at-the-eol rule, which
utterly obliterates its "splice" meaning.
So: can we at least agree that GROUP can be coded as a special case of
what we currently call SPLICE, and rename SPLICE to END? or SPLIT?
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
