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

Reply via email to