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
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
