On 01.02.12 20:32, Kenneth Lerman wrote:
> On 01/31/2012 11:14 PM, Erik Christiansen wrote:
> > Any "need" to know the run-time state of a modality before run-time is
> > illusory. That which needs to be known at run-time needs to be known at
> > run time, not before. It is worth understanding that the run-time value
> > of a modality is not part of the grammar. I'm not sure what you're
> > basing these imaginary concerns on, but I can't relate them to reality,
> > despite some effort :-)
>
> In the past you've implied this,
When dragged off onto the topic of interpreters, I've had to discuss
what happens _at_ run-time. Now let's read the above paragraph again. ;-)
A language grammar specifies permissible input syntax. It knows nothing
about the (changing) run-time values of variables or states (modalities).
An interpreter _uses_ a grammar, not just to translate input into text
output, as a translator or compiler would, but to execute the code.
Now we have jumped into the run-time universe, and need to track state,
just as we track the values of all the variables.
My current understanding is that a modality ought be initialised at the
start of a gcode program, and changes state according to the run-time
path through the gcode, whether that's straight down the page or dizzy
as a fly dodging the corks dangling round the brim of a swaggy's hat.
That's run-time state, not grammar.
> and roughly three or four posts in the future, you bemoan the fact
> that Haberler's trial grammar "is devoid of any explicit gcode
> grammar." My concerns were based on previous statements that you
> thought this should be done.
Please put those concerns to rest. There is no intrinsic connection
between a grammar and run-time values.
The problem with the absence of gcode grammar from a trial grammar is
that we have moved no nearer to documenting the LinuxCNC dialect,
because the so-called parser was only a tokeniser, blindly passing any
text from G0 to G999.9 inclusive, without recognising any difference
between G76 and G497.6, as you can see here:
Lexer:
gcode ({digit}{1,3}((\.{digit})?))
([Gg]{opt_ws}{gcode}) {RETURN_TOKEN(token::TGCODE);}
The parser, as shown upthread, does not receive a value with TGCODE, and
there is only this one token for all ten thousand gcodes that it passes
on like a hollow pipe. The "parser" does _not_even_know_ which gcode it
is blindly letting through. Thus, for LinuxCNC gcode, it is only a
tokeniser in effect, at this stage. Any handling of even one LinuxCNC
gcode remains to be added.
As we were warned when it was posted, it's experimental Mk. 0.1.
My comments just try to clarify what it does now.
> While you could put some grammar rules in place, it is my contention
> that no matter how good the grammar, you will need some semantic
> analysis.
There are clearly different needs out there. The two I'm repeatedly
running back to are; documented grammar, definitely executable, and (if
we can get away with it) a more literate optional input form of the same
LinuxCNC dialect we now use. (There will be some grumbling if it's mixed
in with the grammar for the "kosher" current form. I'll have to look at
keeping them visually separate, if possible.)
...
> In short, I'm suggesting that:
> 1 -- An automated lexer would be useful
> 2 -- An automated parser might be useful (if it can give reasonable
> error messages, etc AND be reasonably modified.) If minor changes
> require digging through shift/reduce conflicts and trying to resolve
> them, that might be reason to avoid such technology.
:-)
It might be worth remembering that shift/reduce conflicts arise from an
ambiguous grammar. Their occurrence help us avoid that. Better a grammar
fix, than unpredictable results in the gcode, when swarf and coolant are
flying.
> 3 -- A semantic analyzer (whether rule based or coded) will be necessary.
Do you want to prove some property of the gcode program, such as whether
it will ever reach the end?
Erik
--
Don't believe everything you hear, or anything you say.
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
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-d2d
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
