Erik, Am 01.02.2012 um 09:23 schrieb Erik Christiansen:
> On 01.02.12 00:05, Michael Haberler wrote: > > (1) > The grammar specifies expression and control flow constructs, but seems > 100% devoid of any explicit gcode grammar. I've scrolled up and down > twice now, but still can't see any rapids, moves, feedrates, or > toolchanges. Nuffin! Yes, and that is a feature. > It seems that any gcode intelligence, which would enable it to parse the > "current linuxcnc dialect", is yet to be added. Interpreters and compilers sport post-parsing phases which work the AST, the symbol table etc to find the more interesting static semantic errors. That's where the 'gcode intelligence' needs to be. Your idea of an exclusively lexical and grammar approach to language analysis will be less than helpful, because: a) the idea of catching errors exclusively at the level of a context free grammar is not going beyond the trivial since many errors in G-code programs are not syntactical or indeed subject to static analysis in nature in the first place. To give a trivial example where your purely lexical/syntactic approach fails completely: Try to check the *compatibility* of several words and their parameters within a block. As this boils down to set operations and then some, for which a context free grammar provides exactly zero help, *any parser* for that matter is bound to stay, as you say, 'incomplete' by definition. Wrong tool, wrench broken. b) the language we have *is already runtime extensible* at the word level and your idea kills this property by downgrading it to a compile-time affair. Anybody wanting to add or redefine a code would have to change the *grammar definition*, which IMO isnt exactly what Joe Chipcutter will just love to do in the evening just because he needs to adjust a code's behaviour, or write a new one. That brings the number of people being able to change an existing, or define a new G- or M-code to epsilon, which is worse than we have now. Task and interpreter have enough of an configurability straightjacket as they stand and we need less, not more IMO. c) language preferences: I remember the original topic to be about an executable language description, reducing syntactic noise, and lint-type tools or prettyprinting for that matter. It was not about rewriting the current interpreter, but if that is your topic: the current interpreter is written in C++, so anybody fiddling with it better have/get some working knowledge of C++ or refrain (I did not have it either and did the former). Plus, language breaks are always excellent opportunities to create new support issues, and I dont see the upside, spare manpower or will to deal with it. > You've prompted me to dig out the parser I started in July, and since > there isn't any actual gcode in yours, I'm probably better off dusting > it off, and playing with it. Sharing any better ideas or results would be helpful. ---- To suggest a productive topic of discussion: lint-type tools, prettyprinters and interpreter extensions by (re) defining codes share some aspects: - they need to work the current parsing result, or better an abstract syntax tree and symbol/type information - they suggest a late binding approach for extensibility reasons This suggests to think about either redoing the whole thing in Python in the first place, or alternatively providing a Python binding for AST and symbol/type information if one were to stay with a C++ parser to remain within the current interpreter framework. That would provide a (potentially common) language base for the LinuxCNC interpreter, and any extra tools around it, which would be a big plus in terms of maintainence and consistency since we dont have the manpower and clue for a dozen of personal parsers, all a bit different. See for example the interesting pycparser project at http://code.google.com/p/pycparser. It uses clang/llvm : http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/ which is a bit on the heavy side for the task at hand, but I already used pycparser successfully to aid in a refactoring task, which was pretty close to prettyprinting and fairly simple to do. any opinions on that? - Michael > > Confirming the growing suspicion, I found only this: > > block: > word > | block word > ; > > word: > letter optional_value > | TGCODE > | TMCODE > > and: > > optional_value: > /* empty */ > | expression > ; > > That will pass any gcode with any parameters, without truly parsing any > of it. My reading of that grammar is that it will, for example, blindly > take G0 with all G76's parameters: > > G0 P- Z- I- J- R- K- Q- H- E- L- > > For a parser to _interpret_ the input gcode, it must recognise the > difference between G0 and G76, and know which options are permitted for > each. This one does not understand gcode at all, AFAICT. Grammars found > lying about on the net are not often complete, and this one is no > exception, apparently. > > If the gcode part of the grammar has fallen off on it's way here, I'd > love to see it. > > (2) > This, which I saw first, hardly seems significant now, but it's a > helpful bit of pedantry, if you're fussy. It's poor grammar to hide > the non-optional TO_ENDIF down in "opt_elseifs", I suggest: > > . > | TO_IF expression lines opt_elseifs > . > ; > > opt_elseifs: > TO_ENDIF > | TO_ELSE lines TO_ENDIF > | TO_ELSIF lines opt_elseifs > ; > > We could document more clearly with a tiny tweak: > > . > | TO_IF expression lines opt_elseifs TO_ENDIF > . > ; > > opt_elseifs: > /* Empty */ > | TO_ELSE lines TO_ENDIF > | TO_ELSIF lines opt_elseifs > ; > > Now the grammar snippet for TO_IF makes sense by itself. > (It now doesn't end in a subclause.) > And opt_elseifs is now what it claims to be - optional. > > OK, where do we go from here? > I'm not able to brew up any enthusiasm for beating 34 conflicts out of > the skeleton of a parser which does not yet have gcode grammar. Sorry. > > Is there any chance of switching your stuff back to C, instead of C++? > I've avoided the latter in my entire 30 developer career, and I wonder > if we'd have more hackers if we just stick to C? > > You've prompted me to dig out the parser I started in July, and since > there isn't any actual gcode in yours, I'm probably better off dusting > it off, and playing with it. > > I'm sorry if that sounds a bit negative, but it's supposed to be just a > neutral record of what I can see. (Maybe I need to go and eat.) > > Erik > > -- > Use C++ to confuse your enemies; use C to produce stable code. > - Wolfgang Denk, on u-boot-users. > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > 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-d2d > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! 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-d2d _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
