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
