On Fri, Feb 22, 2013 at 7:51 AM, David A. Wheeler <dwhee...@dwheeler.com> wrote: > Alan Manuel Gloria: >> I think a different approach is better. > > Definitely a possibility; I'm still trying to figure out if it's possible to > do this in a simpler/cleaner way. > > BTW, I'm realizing that this creates yet another potential problem: Disabled > error-checking. > With this, a line with indentation that doesn't match its parents might be > okay (!). > We may be able to quickly detect that and deal with it; I'd like to make sure > we > can still quickly detect bad indents. > > >> The problem is that DEDENT_PARTIAL cannot give information about >> *how many* ? exist on the indent stack. > > But how much of that information do we really need? > > >> Instead, I think this calls for a more complicated indentation preprocessor: > > (pft)... That's the sound of my head exploding :-). > > I've read that several times and I don't think I fully understand it. > I understand each line separately, but not why you believe they > work properly together. I'm imagining trying to create a math proof that > this algorithm is correct... and failing completely.
Well, so far the only property I can prove is that the number of INDENT's emitted is equal to the the number of DEDENT's emitted. This is due to the fact that every event that pushes an entry on the stack also emits exactly one INDENT, and any event that pops an entry off the stack also emits a DEDENT; the only exception is the part where the top ? item is replaced, and that does not emit either an INDENT or DEDENT, while stack height is preserved. Thus each stack entry represents a pending INDENT that is not yet matched by a DEDENT. As long as we empty the stack at EOF, then every INDENT gets paired at some point with DEDENT. As for SUBLIST working properly, what exactly about SUBLIST should we prove? What needs to get proven in an indentation processor? Basically, this indentation processor is just a more formal expression of what Beni said in his initial email about DEDENT and SUBLIST. > > Also, I can't begin to imagine *explaining* that algorithm to someone. > While the BNF has many lines, many people have had lots of training in > BNFs and can pick them up quickly. Indentation processing like this... not > so much. > > Granted, you could argue that's a limitation on MY end, and that's probably > true enough. But if I have trouble understanding it, I doubt I'm the only > one. > > >> Basically, the formulation would remove all mention of GROUP_SPLIT and >> SUBLIST (and all branches where they occur) but complicate the >> indentation preprocessor. > > That's a significant part of the definition of these expressions, > rendering them basically invisible to automated checking and analysis. > I want this notation to work "because it's clearly correct"; using ANTLR > to check it rigorously is a valuable way to get there. That's a dangerous > loss. I agree. > > Is there a way to simplify this, perhaps by finding some half-way approach? > > I plan to do some experimenting with the ANTLR BNF, and see if there's a way > to tweak what we have while keeping the automated analysis working. > Suggestions welcome. > > --- 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
