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: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
