On 29.01.12 12:59, andy pugh wrote:
> On 29 January 2012 12:29, Erik Christiansen <dva...@internode.on.net> wrote:
>
> > While that could be 'de-hashed' without an alternative numbered
> > parameter identifier, I don't see how you'd propose to handle:
> >
> > #43 = foo / #44
>
> I am puzzled how you would handle
> foo = 10
If the concern is that it could be confused with "F 10", then I'll
cheerfully admit that "F" should be a keyword in the grammar, as it is
to us, and so no variable may be named "F". Thus, there is no problem.
If we imagine a case where disambiguation were not so simple, then a
quick way out is manually coded lookahead. That's not needed here.
> oo = 10000
OK, "O Codes". They'll all go in a declutter, replaced by their naked
keywords, "sub", "call", "endsub", etc. Each is easily recognised by the
lexer, and a unique token ID passed to the parser, so that it
immediately knows which grammar subclauses apply.
We won't be able to have a variable called "call", or a function called
"endsub", but "oo" isn't a keyword, so here it's unambiguously a
variable name, since it is preceded by neither "sub" nor "call".
> g1fooZ100
Is there an axis identifier missing here? If it's supposed to be:
g1YfooZ100
Then the gcode ends at the numeric - alpha transition. The grammar then
demands some {axis_identifier,magnitude} pairs, optionally with embedded
stuff like feedrate. Thus "Y foo" and "Z 100" are easily picked out,
whether spaced or not. Since there is no '#' in front of "100", it is a
literal numeric.
There is no parsing complexity in any of these cases.
> Is it not a significant problem that every single letter of the
> alphabet is already a G-code command?
No, not of itself. So long as we have an unambiguous grammar, then the
parser has no trouble. The grammar tells the parser when a
[xXyYZzUuVvWw] is to be interpreted as an axis ID, rather than the first
letter of a name. To avoid the constraint that a name could not begin
with one of those letters, I would need to employ a stateful lexer, but
that is easy. The parser then fine tunes the lexer's eyesight, token by
token, as it walks along a line of gcode.
Incidentally, spaces in the input are usually eliminated by one line in
the lexer. The parser never sees spaces, so that one line is all the
space handling there is. (Well, that's how I do it, 'cos it's easier.)
The parser is automatically generated from the BNF grammar and its
embedded output actions (coded in C), so it's only necessary to write
the lexer, the grammar, and the leaf actions. The fun begins if the
grammar is ambiguous, resulting in conflicts. Debugging that adds to the
entertainment value.
But I haven't seen a troublesome gcode example yet. :-)
Erik
--
... with proper design, the features come cheaply. This approach is
arduous, but continues to succeed. -Dennis Ritchie
------------------------------------------------------------------------------
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
