On 1/29/2012 10:55 AM, Erik Christiansen wrote: > On 29.01.12 14:20, andy pugh wrote: >> On 29 January 2012 14:02, Erik Christiansen<dva...@internode.on.net> wrote: >> >>>> oo = 10000 >>> OK, "O Codes". They'll all go in a declutter, replaced by their naked >>> keywords, >> No, that is creating a second named parameter in order to be more >> ambiguous later: > Yes, the variable assignment is unmistakable, but the sneaky intent > wasn't. :-) > >>>> g1fooZ100 >>> Is there an axis identifier missing here? If it's supposed to be: >>> >>> g1YfooZ100 >> And here is the question? What did I mean? >> >> I was actually meaning feed at the rate defined by the parameter oo, >> but how is the parser to know that is what I wanted rather than there >> being a missing S (for example) in G1 Sfoo Z100 (not a totally random >> case, my machine has a very reluctant S key, I very often type M31000 >> in MDI) > As it should, a parser slavishly applies its grammar to the input which > we _do_ provide, not what we didn't. In the BNF grammar, we need to > specify that a feedrate_clause may appear after a g1, as an alternative > to an axis_motion. That causes the 'f' to be recognised as a keyword, > which in turn causes "oo" to be detected as a variable name. It is > equally straightforward to allow and optional 'S' clause to this part of > the grammar. > > What further simplifies the task is that we can, for example, group the > clauses which are common to G0, G1, etc., and give them a name. The part > of the grammar tree for G1 then gets the handling of the common clauses > for free, and we only need to tack on the stuff that G0 doesn't have. > Not only does this reduce coding and testing effort, but it ensures > consistency across commands, where it should exist. i.e. Anything which > is even moderately common in gcode should be specified only once in the > grammar. I'd rather NOT have the details of what is mandatory and what is optional for various g-codes be part of the grammar. Right now, it is pretty straightforward to add a new g-code. I don't think we should require modifying the grammar to be necessary to add (or change) a g-code. > > To allow removal of the square brackets currently containing an > axis_motion clause, we need alternative clause termination. Upthread I > suggested ';', as is used between elements of a for loop in most > languages. Your line then becomes: > > g1foo;Z100 > > Or if we are in industry, and someone else might need to read it: > > g1 foo; z100 # Either G&F&Z or g&f&z is easier on humans. > > Now a LALR(1) parser can deal not only with that, but also with a > variable named "foo" or "Foo", so long as we configure a stateful lexer, > which is able to look for only a keyword immediately after the G1, and > resume seeing a variable name after the "f" keyword is consumed. > >> I think we should keep the # for all variables. It is what humans >> reading G-code expect to see. > That is admirably achieved by changing nothing, fully maintaining > historical authenticity. I respect such a preference. > > The purpose of the proposed changes is expressly to eliminate such > useless visual clutter. My expectation is that if we proceed to > implementation, then users will choose to use one syntax or the other. > The two need to be equivalent in function, but the old clutter need not > adhere to the more readable alternative syntax.
I find it interesting that you consider removing (what you refer to as) the clutter makes the code more readable. I consider having the clutter more readable. Removing the clutter makes it easier to write (there are fewer keystrokes). A typography analogy might be useful. My understanding is that fonts with serifs are easier to read than san-serif fonts. I'm sure that it has been suggested that serifs be removed to eliminate clutter. Redundundancy is sometimes useful. :-) > >> A linked point is that we seem to be discussing mainly human-generated >> G-code, whereas a large proportion of G-code executed by EMC2 machines >> is machine-generated. As well as discussing machine-parsing we also >> might need to consider machine-generation. > Yes, it needs to be considered, but I don't quite see an impact. > Compatible machine-generated gcode is currently in the historical > format, and it is adequately handled by the existing parser. > > The purpose of the decluttered parser is to allow human-generated gcode > to become human readable. If, in time, some machine-generated gcode should > transition to the more readable format, then that's OK too. > > One thing with a lex/bison based interpreter is that the implementation > itself contains a BNF specification of the legal grammar. Whether input > is legit or not is easily looked up in one place. And if error messages > are not sufficiently explicit, then it's fairly easy to see if steps can > easily be taken to fix it. > > Erik > Regards, Ken ------------------------------------------------------------------------------ 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