On 29.01.12 23:05, Kenneth Lerman wrote:
> Are you suggesting that a three axis machine where there is
> no A axis should have a different grammar than a four axis machine that
> does have an A axis.
No, there is no such constraint in the current parser, and there is no
reason to imagine that there might be in the new. A language like C does
not constrain whether the user can count by twos or threes, and nor is
there any connection between a gcode grammar and the peculiarities of a
specific machine. One grammar handles them all. I think most users
understand that the machine specifics are entirely dealt with by
run-time configuration and the gcode input.
It is worth understanding that the current parser _does_ have a fixed
grammar, just like the proposed alternative. The significant difference
is that in the current parser, it is not revealed in a concise
human-readable form.
As far as grammars go, the only structural change is transition from an
amorphous hand-coded parser to a structured auto-generated parser, using
a formal BNF grammar specification, instead of an undocumented one.
> How would you specify that G1 can have X Y Z values in any order, but
> only one of each? And that in some cases the X Y or Z values are
> optional if they use the same value as a previous line?
That is trivial, and is achieved without writing any program code to do
it. Multiple alternatives, independent of order, and optional
parameters, are the most basic meat of writing a BNF grammar.
A prior post today shows how a BNF grammar allows alternatives, in any
order. Here is an example of how to allow an optional parameter:
tool_options: /* Empty */
| ',' spindle_directive
As with the rest of the grammar, the code to implement our wishes is
auto-generated. We just have to get the grammar right. ;-)
If you read the early chapters in O'Reilly's "Lex & Yacc" book, you'll
see how completely straightforward these simple cases are. :-)
> Remember, of course, that when we have subroutines, a previous
> line means a previously executed line.
An interpreter must retain the state of any modal directive. That's
rather simple. A translator benefits from doing the same, since it can
then generate better error messages. The grammar example posted earlier
today includes an example of this. It's also pretty simple.
What is being missed here is that the present parser does all that you
fear above, just without the maintainability and documentation benefits
conferred by a higher level implementation, using powerful tools.
Erik
--
In general, they do what you want, unless you want consistency.
- Larry Wall in the perl man page
------------------------------------------------------------------------------
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
