Here are few more, and a quick summary of my thoughts on each.
> > 1. Proposal: Modify modern-expressions so that any expression can be
> > postfixed by () [] {} - currently, only symbol and list expressions
> > can be postfixed.
I think we *should* do this, it's a great idea of yours. At the least, let's
try to implement it & see if there is a hidden problem. If there are no
gotchas, let's do it.
> > 2. Proposal: . as indentation whitespace. LAWLZ
I'm leaning against this, but yet there's something tempting about it :-).
It's just so *weird*. I say that even though it's my idea!
> > 3. Discussion: GROUP, SPLICE, and various permutations on their
> > meanings and semantic characters, including a proposed new "ENLIST".
Yes. That discussion in particular is still ongoing. This includes getting
rid of the proposed "SPLICE at the end" rule.
The one thing that stands out in this discussion is that the "group" marker is
special, yet it uses a normal symbol, and that *is* ugly. We inherited that
from the I-expression spec, but we can move on. But once we admit we can
change that, lots of other options become available, and they're worth
discussing so we pick a good one.
> > 4. Proposal: A new declarative parser spec (which probably confuses
> > most people at this point, sigh)
I'm grateful you did that, actually, because that's hard to do. There is very
little experience in creating specs with indentation, interestingly enough.
I'm not confused, but these things take time to read.
> 5. Proposal: QUOTE WHITESPACE as abbreviation for symbol quote at the
> i-expr parser, similar processing for other quote-related
> abbreviations. Alternative Proposal: Treat QUOTE WHITESPACE et al.
> similarly to current GROUP handling.
Note that the I-expression spec has rules specifically for QUOTE.
6. Proposal: Should ENTER ENTER no longer end an expression?
I don't like this one. The current behavior is to end expressions with ENTER
ENTER, and I think this one is REALLY REALLY important. My earlier experiments
without that showed that failure to support this was REALLY confusing. I think
as long as comment-only lines (possibly preceded with indents) are completely
ignored, and thus can be used to separate contents, we should be okay.
I do understand the desire to support varying line-ending mechanisms, but I
think we can do both pretty easily. If we see CRLF, that's a line; otherwise,
if we see just CR or LF, that's a line.
7. If expressions don't begin at first column, then what?
AMG's new proposal is to DISABLE indentation processing in this case (currently
that does NOT happen). That's a change, but I could easily be convinced of
this. My concern is that it might make silent errors easier.
--- David A. Wheeler
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
