On 01.02.12 00:05, Michael Haberler wrote:
> ok, while this wonderful discussion was raging on, I built a working
> parser for the current linuxcnc dialect, as an experiment in
> feasability (this is NOT an end-user tool!)
It would take all the fun out of it, if it were. :-)
Before using the debug facilities to look at any of the 34 conflicts, I've
so far just glanced at the lexer and parser. On the first scan of the
latter, two things strike me, one significant, and one just a matter of
clarity.
(1)
The grammar specifies expression and control flow constructs, but seems
100% devoid of any explicit gcode grammar. I've scrolled up and down
twice now, but still can't see any rapids, moves, feedrates, or
toolchanges. Nuffin!
It seems that any gcode intelligence, which would enable it to parse the
"current linuxcnc dialect", is yet to be added.
Confirming the growing suspicion, I found only this:
block:
word
| block word
;
word:
letter optional_value
| TGCODE
| TMCODE
and:
optional_value:
/* empty */
| expression
;
That will pass any gcode with any parameters, without truly parsing any
of it. My reading of that grammar is that it will, for example, blindly
take G0 with all G76's parameters:
G0 P- Z- I- J- R- K- Q- H- E- L-
For a parser to _interpret_ the input gcode, it must recognise the
difference between G0 and G76, and know which options are permitted for
each. This one does not understand gcode at all, AFAICT. Grammars found
lying about on the net are not often complete, and this one is no
exception, apparently.
If the gcode part of the grammar has fallen off on it's way here, I'd
love to see it.
(2)
This, which I saw first, hardly seems significant now, but it's a
helpful bit of pedantry, if you're fussy. It's poor grammar to hide
the non-optional TO_ENDIF down in "opt_elseifs", I suggest:
.
| TO_IF expression lines opt_elseifs
.
;
opt_elseifs:
TO_ENDIF
| TO_ELSE lines TO_ENDIF
| TO_ELSIF lines opt_elseifs
;
We could document more clearly with a tiny tweak:
.
| TO_IF expression lines opt_elseifs TO_ENDIF
.
;
opt_elseifs:
/* Empty */
| TO_ELSE lines TO_ENDIF
| TO_ELSIF lines opt_elseifs
;
Now the grammar snippet for TO_IF makes sense by itself.
(It now doesn't end in a subclause.)
And opt_elseifs is now what it claims to be - optional.
OK, where do we go from here?
I'm not able to brew up any enthusiasm for beating 34 conflicts out of
the skeleton of a parser which does not yet have gcode grammar. Sorry.
Is there any chance of switching your stuff back to C, instead of C++?
I've avoided the latter in my entire 30 developer career, and I wonder
if we'd have more hackers if we just stick to C?
You've prompted me to dig out the parser I started in July, and since
there isn't any actual gcode in yours, I'm probably better off dusting
it off, and playing with it.
I'm sorry if that sounds a bit negative, but it's supposed to be just a
neutral record of what I can see. (Maybe I need to go and eat.)
Erik
--
Use C++ to confuse your enemies; use C to produce stable code.
- Wolfgang Denk, on u-boot-users.
------------------------------------------------------------------------------
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
