On 29.01.12 13:12, Kenneth Lerman wrote: > On 1/29/2012 9:02 AM, Erik Christiansen wrote: > > But I haven't seen a troublesome gcode example yet. :-)
> Remember that just because a computer can understand a grammar does not > mean that a person can. (Consider the C++ grammar.) Point taken. (And perl is C++ cubed, with even authors of perl books admitting in print that it is execrable. See sig.) Andy's example with "foo" and "oo" is also a prime example. I had no idea what the example was supposed to mean, but a grammar of your choice would parse it according to the specified rules even if neither of us correctly anticipated the outcome. Gcode should be explicit, and therefore readily understood. Obfuscated examples, such as Andy's are demonstrably not human readable, but a parser should not be confused by them, even if we are. My point is that I believe that all legal gcode is eminently parsable, and I have yet to see any supposedly pathological gcode example which is very difficult to parse. > Also, I'd like to add a requirement to have variables with "string" > values (together with some added functions). That's so someone could > write code that does engraving. That sounds like fun, but I'm not sure how you'd get from ascii to the G1 moves to produce any font at all. Isn't ascii to gcode a cam function? "The interpreter doesn't generate gcode." is more or less our primary maxim, AIUI. > Someone commented about the comment syntax -- using parens to delimit > comments -- in a somewhat deprecating manner. I'd suggest that it is > certainly no worse than the /* */ comments in my favorite language. I do > find it useful to be able to embed a comment in the middle of a line; > not just at the end. Ah, yes, shouldn't exclude embedded comments I suppose. How about [This is a comment], or "This comment style frees up () too." It's the conflict with the greater utility of () in functions and expressions, which complicates a parser. Replacing the square brackets with the more conventional parentheses reduces gcode,s weirdness, making it human readable with less mind-twisting when moving from all the other scripting languages an integrator is exposed to. The embryonic human_readable_syntax to gcode translator which I started in july last year, using lex/bison, does use the # as comment delimiter, but I could easily add "This comment style" as well, allowing use of either. It's not an attempt at an alternative interpreter, but would simply be run as a filter. It would need quite some work before being ready for prime time, since the current input syntax is made highly readable by using English words which state what is to happen, rather than cryptic gcode non-mnemonic cryptic numbers. Gcode veterans would hate it with a vengeance. For any chance of broader appeal, I'd have to make it also accept conventional gcode with only decluttering added, I see. I'll have a look at what it'll take to do that. (Just a suite of alternative grammar clauses, one up from the leaf level, I expect.) Erik -- Yes, sometimes Perl looks like line-noise to the uninitiated, but to the seasoned Perl programmer, it looks like checksummed line-noise with a mission in life. - The Llama Book ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
