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