I said: > > * After looking at your try at the spec, I think I see how to do it (and in > > a simpler way) with INDENT/DEDENT/SAME. So let's try that to start with. > > We may need to tackle it several times before we get a clear model, another > > reason to wait to deal with the BNF of n-expressions.
Alan Manuel Gloria: > There are some issues here. > > For example, I assume that the n-expr production will end up also > encountering INDENT/DEDENT/SAME tokens. No, not the way I'm thinking about it; see below. ... > If we switch tokenizers, then we need to have some serious thought on > the mechanics of that switching! And that implies (I think, maybe > you'll get a better idea) using something like my parameterized spec- > formulation. The original SRFI-49 used INDENT/DEDENT, but that is awkward to use with our other constructs. What's more, it implies a "tokenizer" that makes things complicated. That complication is unnecessary, since the current implementation doesn't use one. In fact, since the SRFI-49 and our implementation don't really create a INDENT/DEDENT tokenizer, the code doesn't obviously correlate with the BNF. I'd like the BNF and code to "obviously correlate". I like and plan to steal some pieces of your formalization. However, all the "if..." and parenthesized parameters of it seem very complicated. For example, there's a lot of long magic phrases that are nevertheless very similar. Also, they seem to imply a particular implementation; we don't want to mandate a particular implementation approach, just the results. But your "if..." approach got me to thinking about an alternative that I'm trying out. Instead of treating INDENT as a token produced by a tokenizer, why not think of INDENT as a special *guard* that must be *tested* for its truth value? In this case, "INDENT" means "the current indent level is deeper than when this production first started". Then we can isolate all the magic of the "if..." statements in only a few fixed places (in INDENT, SAME, and whatever consumes the indent). That solves a lot problems at a stroke, for example, since you don't consume indent, you don't need to track its consumption (you can always check again later). The complexity is hidden in a only few items, and doesn't grow as you add more productions. To use the current implementation approach we still need to pass around the indentation information, but notionally it's much simpler. Basically, "if the production uses INDENT/SAME or consumes the indent, you have to pass in the current indent and pass out the new indent". That would mean that the BNF and code would obviously correlate. And that's only at the implementation level; no need to mandate it as the One True Implementation. Anyway, give me a day or two & I'll post a start, and let's see if that's better way forward. I'm basically trying to steal ideas from your BNF, my older BNF, and SRFI-49 to create a start using this different semantic for INDENT and SAME. > Formalization is a tricky thing. Yes indeed. :-). > Incidentally, I think it's fortunate that I wrote letterfall - if we > decide to reorg the code, we have something substantial to test it on > ^^ Yes, we also have sweeten & the test case suite too. --- David A. Wheeler ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
