The use of matching labels to resolve ambiguity was just a cheap trick to lower the cost of implementation. There is no reason that we should keep the labels on control structures. We should then follow the same rules that C uses.
Ken On 2/4/2012 10:25 AM, Michael Haberler wrote: > {this is a bit of language/compiler theory, but then the thread started here; > sorry;)} > > One of ideas floating around was to to document the current language as an > EBNF, or an equivalent railroad diagram. An EBNF is a notation for a > context-free languages. > > That will not work, because the current LinuxCNC RS274NGC dialect cannot be > described by a context-free grammar in the first place, and hence not as an > EBNF, if one tries to include the control structures as language elements. > > This is different from the original language: the pre-oword syntax was > context-free, which is why there's a meaningful EBNF in the Tom Kramer > report, and working context-free parsers based on ANTLR and bison like here: > http://fennetic.net/irc/emc3/src/emc/interpreter/) > > To see why the current language is context-sensitive, consider just one > example: > > <<program start>> > o label1 do > ... > o label2 while .. > ... > o label3 endwhile > ... > o label4 while .. > <<eof>> > > You cannot determine by looking at a context-free grammar alone wether the > interpretation should be either: > > 1: (do ... while) (endwhile...while) or: > 2: (do ... (while ... endwhile) ... while) > > To resolve the ambiguity in scope, one needs to match the label *values*: > > (label1 == label4)&& (label2 == label3) -> interpretation 1 (in the current > language) > (label1 != label2) -> an error at 'endwhile' > > This also applies to if/then/elsif/else and repeat/endrepeat. > > So the labels constitute the context. Technically, since the labels are > variable keywords, this means a language with a theoretically infinite > alphabet. > > This has a couple of consequences: > > - writing an EBNF is only possibly on a line-by-line basis, not including the > control structures . But then such an EBNF will not tell you wether a given > program is correct wrt current scoping rules, or not, and as such fairly > useless. > > - it also means explains why my first attempt at a bison/flex parser *for the > current language* failed to properly recognize current control structures > because as it the stands the parser fails at the above ambiguities. This also > applies to other tools. > > This does not mean these tools are unusable, it just means the scanner needs > to tie into the parser or scope stack. It does however mean an EBNF will not > fully encompass all aspects of the language. This might be useful already. > > - Michael > > ps: this is a clarification of what we have, not a critique - C, and C++ have > similar issues and work just fine, too. > > psps: so much for the comment 'G-code is extremely easy to parse.' ;) > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users