sure, but either way you look at it: if there's a language change, there still
be a need for recognizing the old syntax, either for in-place compatibility or
external automatic conversion
-m
Am 04.02.2012 um 22:25 schrieb Kenneth Lerman:
> 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
------------------------------------------------------------------------------
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
