On 01/30/2012 12:28 AM, Erik Christiansen wrote: > 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 > No. I don't think so.
The current implementation does it; not the current parser. If we go back to the compilation/execution analogy, some error conditions are detected at run time; not at compile time. I don't see how the parser can require that G1 has an Fn clause defined on the same or some previously executed line. The parser knows nothing about execution order; only about lexical order. Since the Fn might be hidden away in some subroutine, the parse might not have seen it. I would think that knowing whether an Fn is active is a difficult problem when looking from the outside, but a simple problem from the inside of the run time environment. (Of course, feel free to prove me wrong.) Don't get me wrong. I agree that we need a better definition of the grammar and a more structured implementation. In general, though, I prefer recursive descent parsers such as the present parser that is used for each line. I consider the ability to generate excellent diagnostic and error messages to be worth the effort of hand coding. I recognize that my control structure (o-word) implementation leaves a lot to be desired -- to say the least. About its only saving grace is that it enables us to do a lot of things we couldn't do before. It must be redone in a way that is obviously correct and maintainable. I haven't looked closely at modern automated tools for doing this in a few decades. If they let us generate effective diagnostic information in a straightforward way, we should be using them. On the other hand, the grammar should be simple enough that a hand generated recursive descent parser should do fine. Regards, Ken 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
