On 06.02.12 09:05, dave wrote: > andy pugh <bodge...@gmail.com> wrote: > > So: > > G95 G96 G7 > > M3 S500 > > G1 X100 Z50 > > > > Might become: > > SpindleOn(mode=CSS, Speed=500) > > Feed(X=100, Z=50, mode=FeedPerRev) > > Did this just break coordinated feed? > I must say the clarity is better but you must be COBOL fans; way too > verbose.
In order to please several camps, I think that support for at least two grammar forms, one concise, and one more descriptive, will be essential. There is little or no difficulty supporting both in the one parser, I find. If the concise form is just the current dialect, stripped of noise characters to make it less cluttered, then that might almost please traditionalists and those who don't like typing. The more descriptive form only needs to make more explicit what is programmed. It doesn't need more brackets. A simple structure of a verb followed by nouns and adjectives adheres to the gcode tradition, and is easy to read. Instead of: SpindleOn(mode=CSS, Speed=500) let's have: Spindle On mode=CSS Speed=500 Now the same verb can take different arguments: Spindle Off So that the programmer is dealing with a _language_ with perceptible structure, not just a great big pile of function calls to remember. Requiring spaces between arguments ensures that programs are that little bit more readable. (i.e. Respect the poor bloke who later has to deal with what I've done here. It might be me!) > G-code is terse and efficient. The other does look somewhat like > functions calls. The idea of a new interp I find interesting but as a > simple user it may not do much I need done. That is OK as long as I > don't have to use it. That said the syntax for subroutines could use > some help. Is something more structured and language-like, whether like the simple literate grammar I've described above, or different, more helpful? > I have other problems with the present interp but since I need to > upgrade my mb and switch to 2.5 I will keep silent until I can test > under the new system. Please don't do that, if you can spare the time. We need open-minded constructive contributions like yours, to keep us language nuts on track. (Any visible track, not just some "right" track. ;-) > The discussion here is good and if you grammer/parser people don't lose > the rest of us in the fog ..... interesting. We are still in an early exploratory phase, rich in ideas and proposals. That will hopefully help us optimise one or more promising language forms before committing a lot of development effort. Unfortunately, we get carried away with a bit of _how_, rabbiting on about technicalities, when the broader audience may only wish to read through _what_ is being considered. Hopefully the more opaque lumps of that fog can just be skipped, without losing the gist of the discussion. It would be a pity to have remained silent, only to be faced later with an implementation which lacks a practical feature which might make everyone's life a bit easier. Erik -- I have yet to see any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated. - Poul Anderson ------------------------------------------------------------------------------ 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