Am 29.01.2012 um 06:37 schrieb Erik Christiansen: > > >> - wouldnt it be more readable to write: >> >> ---------------------- >> $var1 = $foo + 1 >> $var2 = 10 >> >> if $var1 < $var 2 >> ... >> else >> ... >> endif >> ---------------------- > > Indeedy, but even the '$' is unnecessary.
I'm not sure whether thats possible in all cases. There are several syntactic constructs - blocks, expressions, assignments and control structures. The noise in expressions really is only needed within blocks; in assignments, and expressions within control structure probably can be completely 'de-noised' and probably 'de-dollared' and partially 'de-hashed' too;). as Ken laid out, the tough decision is disambiguating within blocks by re-introducing whitespace as delimiter; or stay with using brackets to delimit expressions. I think its possible to: - make the bracketing requirement for expressions and assignments in control structure tests optional; - drop the #<> requirement for named variables references and assignments in above; an introducer for numbered params is still needed - make the bracketing requirement *within* expressions optional. - introduce more natural aliases for the EQ/NE/LT etc operators I'm unsure whether the () comment syntax can be disambiguated from normal function parameter lists like atan(param); this might need a backtracking parser or stay with brackets and there isnt much that gain. This is untested conjecture, but I think one could come up with a grammar which would still parse the current language and be able to write: sub func ;blablah endsub baz = 0.45 foo = atan[bar * 47.11] ; possible foo = atan(bar * 47.11) ; unsure - guess not; no much gain either #43 = foo / 10 if foo > bar g10 x[foo * baz] else g0 y[baz] z#43 x[func[10]] ; likely possible g0 y[baz] z#43 x[func(10)] ; I guess not endif that's less filling, but in effect requires bracketing expressions ins block, without requiring it elsewhere, which is a bit confusing. It's one possible route. The other is the 'dont squash whitespace' route. That is a big decision since the latter isnt backwards compatible. What I could think of is use Scott's idea of a pretty printer for the current language, which could introduce whitespace in blocks as needed. The output would likely be compatible with a 'dont squash whitespace' parser. To stay with Ken's example, it could rewrite: 'X#<A>Y#<B>' into 'X#<A> Y#<B>' after which it is possible to drop the #<> variable delimiters and rewrite again into new syntax: 'XA YB' which would be equivalent to 'X#<A> Y#<B>' in the old syntax (or 'X$A Y$A' - whatever the ensuing inspired discussion diligently shepherded by the EMC board will arrive at ;) that would mean that despite the non-backwards compatible language change automatic upgrade is possible > Both in the code, selected in the config file or on the command line, > perhaps? Or mandate a "gcode+" keyword on the first line of input, to > allow either type at run-time? the latter would break backwards compatibility - that keyword and the rest of the file in 'old rs274ngc' syntax wouldnt parse, at least not now and with old versions of linuxcnc. > Manually, a custom regression testing framework, or move to DejaGnu? IMO the next person to introduce another piece of TCL to linuxcnc should be damned to use Forth exclusively for the rest of her life. The primary benefit of TCL was to get John Ousterhout tenure at Berkeley, but then LSD and BSD came from there too, no coincidence IMO ;) That shouldnt prevent us to look for a more comprehensive regression testing framework. Testing GUI applications 'end to end' is lacking sorely, btw. > If we could move to a BNF specification of our permissible grammar, then > the problem would diminish, I think. An example of a flex/bison parser for something which might eventually resemble rs274ngc, in c++, plumbed into the linuxcnc build system (Submakefile) is in http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/parser-v2-dev Its fairly useless and defunct right now but if somebody wants to play based on an example which builds its a start. The grammar in the fennic.net parser needs a lot of work, and the EBNF from the Tom Kramer paper too. -m ------------------------------------------------------------------------------ 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
