On 1/22/2012 4:46 AM, Michael Haberler wrote: > well, my requirements for a vehicle would be roughly like so: > > - industrial-strength error diagnosis and recovery, LALR(1) capable > - can generate a C/C++ scanner/parser from grammer, lexical definition > - the parser/scanner can be used from C/C++ or Python > - optional parse tree generation a plus > - mainstream/widely used code base a plus > > that probably suggests some bison or byacc base; I'd refrain from a > Python-only solution like PLY because that's bound to diverge from the > current interpreter since it cant be easily used a frontend; however, there > was some discussion about moving the interpreter to fully-Python. I think > thats overly ambitious given the resources though. Michael:
I think your list of requirements is a good one and the goal being discussed admirable. I just feel an urge to throw out a caution about your first requirement. I never got past idly playing with the primordial Unix tools lex and yacc but I when I was actively engaged in the fledgling ISO/STEP activity I watched closely as one of NIST's best programmers constructed a reference implementation of a compiler for EXPRESS, the language the STEP committee developed for expressing information models. He used all the classic compiler construction techniques of the late 1980s. You'd think he was working against your list of requirements---or the "dragon book." The result was a program that was excellent in a maddening way. If the input schema were correct, the compiler would run to completion and create lots of "stuff" that was needed in the creation of software tools to work with STEP data. It was widely used inside and outside NIST in the creation of production code. However, if the input schema were incorrect, the compiler would effectively roll over on its back and die. Sure, it emitted error messages but they were obtuse and seldom useful. The folks in the ISO/STEP committee writing EXPRESS schemas for their various application protocols went crazy trying to use his compiler as a diagnostic tool. Their mode of operation was, write a schema, submit, amend the schema, submit, looping as many times as needed to get the compiler to stop failing. I had conversations with the author about the need for a "student" compiler---similar in concept to the Waterloo FORTRAN compilers of the 1960s and 1970s [you youngsters can look them up]---that provided copious and useful error and warning messages. His response was that 1) it was much harder to say what is wrong than to say something is wrong and 2) there was no resource to do all the additional work required. (Actually there was also a 3---if I were so committed to the idea, why didn't I "just do it"?) In particular, he convinced me it is generally difficult to implement meaningful error messages in an LALR parser. (Something I've since read in various books.) OK, so EXPRESS is a much more complicated language but I think the situation may be similar with G-code. To develop 'industrial-strength error diagnosis and recovery" requires great discipline. I suspect it might even be better not to use the lex/yacc (flex/bison) approach at all if one is trying to develop a stand-alone diagnostic tool similar to "lint". But, hey, this is just one man's opinion. The first thing I would do if I were determined to go this route is to take the fledging grammar from Tom Kramer's paper, amend it as necessary to reflect the LinuxCNC additions to RS274/NGC (testing, of course, to see that the result is a valid BNF grammar), pass it through the toolchain of choice, and see what it gives me to work with. I suppose the current LinuxCNC interpreter was heavily influenced by Tom Kramer's original RS274/NGC interpreter code. There's a late-model version of this code at http://code.google.com/p/rs274ngc/ (aside-This version has obviously been touched by others since it now bears a copyright statement by Mark Pictor, whom I do not know. The original NIST code was not subject to copyright.) I have no idea whether Tom passed his grammar through lex/yacc in the creation of his intepreter but you can ask him or Mark Pictor. Their email addresses are listed on the Google project page. > I have zero Java clue and would try to avoid adding another language to the > linuxcnc language plethora, which needs to be pruned rather than be added to I absolutely agree. In the early days of LinuxCNC development, one critic in particular returned to this complaint again and again. I see it as the price one pays for open-source development in a widely distributed, sparsely populated community that changes over time. One never knows what will be the language preference of the person with the next great idea (of course this only matters if the person is sufficiently committed to the idea to implement it). We already have shell scripts, C, C++, tcl/tk, Python (what did I leave out?). Let's not add Java if we can help it. It's better to let some interested party create JLinuxCNC in its entirety. Just my two cents worth. Regards, Kent ------------------------------------------------------------------------------ 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
