I said:
> > I have a *lot* of concerns with that particular construct.

Alan Manuel Gloria:
> Why?  Compare:

It's not "must never happen", but I have a lot of concerns.  Here are ones that 
come to mind:

1. It really complicates explanation and implementation of "$".  Some people 
require a second explanation now, and "$" is really simple. Adding this 
capability to "$" makes it much more complicated to describe.  Every time we 
add a complication, we risk losing some potential users and implementers.

2. I'm not sure that there's enough *value* to adding it.  There *ARE* use 
cases, and these use cases are definitely common enough to discuss doing 
something special with them.  But I worry that the contravening downsides will 
overwhelm it.  Currently, in certain cases we have to add "\\"-only lines; 
that's not really a hardship, especially since the resulting constructs are 
pretty easy to understand.

3. It can be viewed as complicating the reading of code that uses it.  Up to 
this point, a dedent always ended the whole line above; now it can end it a 
part.  Perhaps the reduction in line count is fair compensation; that's not 
clear to me.

4. There's already a body of material on how to handle indentation-based 
languages, which tend to follow Python approaches and specifically do NOT 
differentiate between "indent 3 spaces" and "indent 1 space", just INDENT.  We 
leave better-understood parsing theory if we do this.  I want to have it easily 
implemented, with many reasons to be *confident* it is well-designed... the 
more we leave established theory, the harder it is to do that.

Let me speak to the last point.  If we *did* go this way (and I'm dubious right 
now), we need to make sure that this construct is clearly and unambiguously 
defined as part of some well-checked BNF grammar.  Turning every space into an 
INDENT, and reduced space into a DEDENT, seems to make this much worse.   I 
don't know of anyone who handles indent/dedent processing this way; people 
normally tokenize indentation to make parsing easier.  I want to stick to 
better-understood ground where we can, so we avoid any surprise disasters.

So if we went this way, I suspect it would be better to model this by adding a 
new indentation token, DEDENT_PARTIAL, in addition to DEDENT.  A DEDENT undents 
back to the previous parent level; a DEDENT_PARTIAL undents back to something 
consistent with the parent and the current indent, but is (strictly) between 
them.  The indent parser would have to change to generate a DEDENT_PARTIAL, and 
the BNF would have to change to support DEDENT_PARTIAL.  That way, we at least 
continue to tokenize indentation changes.  I don't know if the BNF change would 
be easy or hard; if it's hard, I'm *really* disinclined.

Anyone want to try out trying to define this meaning in BNF using 
DEDENT_PARTIAL?  Seeing what it would mean, as a BNF, might make it much easier 
to understand its pros and cons.

--- David A. Wheeler

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