On 07.02.12 09:47, andy pugh wrote:
> On 7 February 2012 05:34, Erik Christiansen <dva...@internode.on.net> wrote:
>
> > 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.
>
> I can certainly see an advantage in an interpreter where every G-code
> instruction maps to a one or two word phrase in English
We just need to make it so natural to the programmer that it is easier
to master than raw gcode. Your example above leads us further down the
road of programming _what_ we want, than I had originally dared, by
programming common multiple-gcode constructs in one natural phrase.
Spindle On mode=CSS Speed=500
generates something like:
G96 S500 M3
And
Spindle On CCW mode=CSS Speed=500
gives us:
G96 S500 M4
To allow us to program "G96 D3000 S500", this time not starting the
spindle, we also need to support:
Spindle mode=CSS Revs<3000 Speed=500
What we can easily do is accept the legal combinations of these
components of spindle control, while erroring on any which LinuxCNC
currently won't take. Accepting them in any order makes it a little
awkward to detect if any of them are repeated (e.g. Speed=500 mode=CSS
Speed=3000), but it's not really difficult.
> (and, for fun, in French, Polish, German...)
Oh that is wickedly tempting. :-))
If the user is willing to run "make" with a language selection argument,
it's not hard to make the grammar handle alternative spoken languages
for the verbs, adverbs, etc. We'd just need a table for each language,
each in a separate file. The rest wouldn't take too much effort.
For international exchange, a bit of awk or perl (ok, python maybe)
could translate source files.
> Your suggestion goes a little further, in that "mode" and "speed" are
> context-dependent in a way that S and F are not, but it seems that a
> suitable lexer/parser/interpreter could cope.
>
> One would have to guard against:
> #<pindle> = 2000
> S#<pindle>
> if the alternative syntax of
> pindle = 2000
> Spindle
> were allowed :-)
You have a devious mind, Andy. It's an asset to many endeavours,
including really testing these mind-castles we're building. Fortunately
in this case, the castle is well defended. :-)
Assignments are handled by the "expressions" clause of a grammar, while
"Spindle" syntax is handled higher up, in another clause. As a
consequence, the required protection accrues fairly naturally. Even if
we were loony, and allowed a variable to be called "Spindle", and could
get that keyword through the lexer as a variable name, the parser's
one-token lookahead can distinguish between "Spindle On ..." and
"Spindle =", shunting our parser down the right grammar tracks at the
last instant before it would be derailed.
Thanks for the insight into relinquishing one-to-one correspondence
between input verbs and G/M-codes. That little nudge gives us scope for
a more natural language, which is easier to both program and read.
Erik
--
If you understand what you're doing, you're not learning anything.
- A. L.
"Fully" ... I hope he means "Fully". - Erik
------------------------------------------------------------------------------
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
