On 01/29/2012 10:40 PM, Erik Christiansen wrote: > On 29.01.12 13:30, Kenneth Lerman wrote: >> On 1/29/2012 10:55 AM, Erik Christiansen wrote: >>> 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. > Ohhhhhhhhhhhhh Deeeeeeeaaaaaaaaarrrrrrrrrr, that's a bit of a problem. > You see, having a BNF grammar specification to eliminate any confusion > over what is legal syntax, is a major purpose of the improvement. > (I believe it is broadly considered a defect in the current parser.) I would put the details of what letter codes are valid for which gcodes in the semantics of the implementation of the particular code (the way it is now). 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.
I don't believe it would be reasonable to specify the total grammar the way you suggest using BNF. 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? Remember, of course, that when we have subroutines, a previous line means a previously executed line. Ken > It is worth understanding that it is not possible to intelligently > generate error messages if the grammar fails to specify "what is > mandatory and what is optional for various g-codes". Clearly, that is > the explicit _purpose_ of the grammar. > > Having that BNF grammar specification embedded in the new parser means > that it abides by the language specification. A coder cannot diddle the > parsing significantly in a corner of the code. > > Changing the BNF specification, and filling in the blanks in the leaf > code, _is_ adding or changing the legal gcode. Nothing else needs to be > done, other than update the documentation, since the parser is > auto-generated from the few keystrokes we have added. > > The process is disciplined, highly structured, and minimises hand coding > to the nth degree. There's not a lot of code to wade through. > (Some people will hate it. ;-) > ... > >>> 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). > The "change nothing" preference is admirably handled by the existing > parser. The alternative syntax can be expected to be alternative. ;-) > > My interest in this was reawakened by others expressing distaste at the > obfuscating clutter in the current gcode syntax, yet again. When there's > enough interest, we'll do something about it. > >> 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. > I prefer to avoid that clutter too, and don't use serif fonts. > > If syntax highlighting is used to impose different colours on different > parts of some code within a line, then I have trouble reading it. > >> Redundundancy is sometimes useful. :-) > Hmmm, I don't think it exists in mathematical or programming > expressions, and I abhor it in gcode. To my mind, it only introduces > potential conflict between the parts of the unnecessary duplication. > However, what we have in gcode is not redundancy, but clutter lacking in > any information content of any kind. The variable and function names, as > well as keywords, contain _all_ of the information in their alphanum > names. The surrounding crutches for low capability parsers give nothing to > the user. > > Erik > ------------------------------------------------------------------------------ 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
