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

Reply via email to