On Feb 18, 2013 10:11 PM, "David A. Wheeler" <dwhee...@dwheeler.com> wrote:
> Beni Cherniavsky-Paskin:
> > A common objection to any scheme allowing unmatched dedents is that it
> > requires lookahead, both for machine parsing *and humans*.  When you
> ...
> > But in our case, $ already declares that we opened an inner construct,
so I
> > think it won't be surprising to humans.
> Points for cleverness, at least!
> But I think the required human look-ahead for this idea is a terrible
> Having to possibly scan a lot of future lines to understand the local
meaning is, I think, a
> net *loss* to readability.  I'm skeptical that it wouldn't be
"surprising" to humans,
> but even so, the human still has to do the lookahead with such a
> When I'm programming or debugging I already
> have enough to keep track of!
I agree that requiring humans to look ahead would be terrible.
I'm only proposing this since as I see it it does NOT happen here.  The $
opened the list anyway; the only thing you don't expect up-front is that
this list can be closed without immediately closing the surrounding list.
The same is also true with s-expressions - encountering the dedent is
equivallent to encountering a ")".

> > You cannot express (outer1 outer2 (inner1 inner2) outer3)
> > without giving up on use of $.
> True, but there are non-$ forms that are pretty easy to use and read
> with the current notation, such as:
> outer1 outer2
> ! inner1 inner2
> ! outer3
I forgot to mention that I don't have a justification why we need it.  I
felt it's a natural extension, but it's not a must.
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Readable-discuss mailing list

Reply via email to