FYI, here's a detailed point about the BNF I posted; if anyone thinks it's a problem, please reply.
The BNF I posted does assume that the "n-expression" reader greedily reads the tail, e.g., in a(x) the "(x)" part. Basically, when it reads the tail, it keeps looking for "(", "[", or "{" and assumes matches are another part of the tail... otherwise, it's not and we're done. That's the "obvious" way to implement the tail, in fact, it'd be a pain to do otherwise in a Scheme implementation. It's also trivial to do in ANTLR. In fact, I'd expect most LL(1) readers to implement this "ambiguity" in the same way by preferring the direct rule in the tail (this is similar to the "trailing else" issue in many languages). I tried writing the BNF without that assumption, but the BNF productions become really hairy and complicated, for no gain in understanding or implementation. In particular, the productions have a number of places where the sequence "hspace* (X | eol_comment)" occurs; they would have to become something like ((hspace+ (X | eol_comment) | eol_comment), so that trailing horizontal whitespace on a line would be correctly ignored. In an implementation, just look for 3 characters while implementing the tail, and "hspace*" is trivially implemented by consuming all spaces and tabs. This means that: #;a#|hi|#(x) z is interpreted as (a (x) z), and not ((a x) z). I doubt many people would use such bizarre constructs, and even if they did, I think interpreting a#|hi|#(x) as being *separated* by #|...|# is consistent with normal Scheme rules and *should* be the way it's interpreted. --- David A. Wheeler ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss