On 1/29/2012 9:02 AM, Erik Christiansen wrote:
> On 29.01.12 12:59, andy pugh wrote:
>> On 29 January 2012 12:29, Erik Christiansen<dva...@internode.on.net> wrote:
>>
>>> While that could be 'de-hashed' without an alternative numbered
>>> parameter identifier, I don't see how you'd propose to handle:
>>>
>>> #43 = foo / #44
>> I am puzzled how you would handle
>> foo = 10
> If the concern is that it could be confused with "F 10", then I'll
> cheerfully admit that "F" should be a keyword in the grammar, as it is
> to us, and so no variable may be named "F". Thus, there is no problem.
>
> If we imagine a case where disambiguation were not so simple, then a
> quick way out is manually coded lookahead. That's not needed here.
>
>> oo = 10000
> OK, "O Codes". They'll all go in a declutter, replaced by their naked
> keywords, "sub", "call", "endsub", etc. Each is easily recognised by the
> lexer, and a unique token ID passed to the parser, so that it
> immediately knows which grammar subclauses apply.
>
> We won't be able to have a variable called "call", or a function called
> "endsub", but "oo" isn't a keyword, so here it's unambiguously a
> variable name, since it is preceded by neither "sub" nor "call".
>
>> g1fooZ100
> Is there an axis identifier missing here? If it's supposed to be:
>
> g1YfooZ100
>
> Then the gcode ends at the numeric - alpha transition. The grammar then
> demands some {axis_identifier,magnitude} pairs, optionally with embedded
> stuff like feedrate. Thus "Y foo" and "Z 100" are easily picked out,
> whether spaced or not. Since there is no '#' in front of "100", it is a
> literal numeric.
>
> There is no parsing complexity in any of these cases.
>
>> Is it not a significant problem that every single letter of the
>> alphabet is already a G-code command?
> No, not of itself. So long as we have an unambiguous grammar, then the
> parser has no trouble. The grammar tells the parser when a
> [xXyYZzUuVvWw] is to be interpreted as an axis ID, rather than the first
> letter of a name. To avoid the constraint that a name could not begin
> with one of those letters, I would need to employ a stateful lexer, but
> that is easy. The parser then fine tunes the lexer's eyesight, token by
> token, as it walks along a line of gcode.
>
> Incidentally, spaces in the input are usually eliminated by one line in
> the lexer. The parser never sees spaces, so that one line is all the
> space handling there is. (Well, that's how I do it, 'cos it's easier.)
>
> The parser is automatically generated from the BNF grammar and its
> embedded output actions (coded in C), so it's only necessary to write
> the lexer, the grammar, and the leaf actions. The fun begins if the
> grammar is ambiguous, resulting in conflicts. Debugging that adds to the
> entertainment value.
>
> But I haven't seen a troublesome gcode example yet. :-)
>
> Erik
>
Remember that just because a computer can understand a grammar does not
mean that a person can. (Consider the C++ grammar.)
Also, I'd like to add a requirement to have variables with "string"
values (together with some added functions). That's so someone could
write code that does engraving.
Someone commented about the comment syntax -- using parens to delimit
comments -- in a somewhat deprecating manner. I'd suggest that it is
certainly no worse than the /* */ comments in my favorite language. I do
find it useful to be able to embed a comment in the middle of a line;
not just at the end.
Ken
------------------------------------------------------------------------------
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
