On 29.01.12 13:30, Kenneth Lerman wrote:
> On 1/29/2012 10:55 AM, Erik Christiansen wrote:
> > What further simplifies the task is that we can, for example, group the
> > clauses which are common to G0, G1, etc., and give them a name. The part
> > of the grammar tree for G1 then gets the handling of the common clauses
> > for free, and we only need to tack on the stuff that G0 doesn't have.
> > Not only does this reduce coding and testing effort, but it ensures
> > consistency across commands, where it should exist. i.e. Anything which
> > is even moderately common in gcode should be specified only once in the
> > grammar.
> I'd rather NOT have the details of what is mandatory and what is
> optional for various g-codes be part of the grammar. Right now, it is
> pretty straightforward to add a new g-code. I don't think we should
> require modifying the grammar to be necessary to add (or change) a g-code.
Ohhhhhhhhhhhhh Deeeeeeeaaaaaaaaarrrrrrrrrr, that's a bit of a problem.
You see, having a BNF grammar specification to eliminate any confusion
over what is legal syntax, is a major purpose of the improvement.
(I believe it is broadly considered a defect in the current parser.)
It is worth understanding that it is not possible to intelligently
generate error messages if the grammar fails to specify "what is
mandatory and what is optional for various g-codes". Clearly, that is
the explicit _purpose_ of the grammar.
Having that BNF grammar specification embedded in the new parser means
that it abides by the language specification. A coder cannot diddle the
parsing significantly in a corner of the code.
Changing the BNF specification, and filling in the blanks in the leaf
code, _is_ adding or changing the legal gcode. Nothing else needs to be
done, other than update the documentation, since the parser is
auto-generated from the few keystrokes we have added.
The process is disciplined, highly structured, and minimises hand coding
to the nth degree. There's not a lot of code to wade through.
(Some people will hate it. ;-)
...
> > The purpose of the proposed changes is expressly to eliminate such
> > useless visual clutter. My expectation is that if we proceed to
> > implementation, then users will choose to use one syntax or the other.
> > The two need to be equivalent in function, but the old clutter need not
> > adhere to the more readable alternative syntax.
>
> I find it interesting that you consider removing (what you refer to as)
> the clutter makes the code more readable. I consider having the clutter
> more readable. Removing the clutter makes it easier to write (there are
> fewer keystrokes).
The "change nothing" preference is admirably handled by the existing
parser. The alternative syntax can be expected to be alternative. ;-)
My interest in this was reawakened by others expressing distaste at the
obfuscating clutter in the current gcode syntax, yet again. When there's
enough interest, we'll do something about it.
> A typography analogy might be useful. My understanding is that fonts
> with serifs are easier to read than san-serif fonts. I'm sure that it
> has been suggested that serifs be removed to eliminate clutter.
I prefer to avoid that clutter too, and don't use serif fonts.
If syntax highlighting is used to impose different colours on different
parts of some code within a line, then I have trouble reading it.
> Redundundancy is sometimes useful. :-)
Hmmm, I don't think it exists in mathematical or programming
expressions, and I abhor it in gcode. To my mind, it only introduces
potential conflict between the parts of the unnecessary duplication.
However, what we have in gcode is not redundancy, but clutter lacking in
any information content of any kind. The variable and function names, as
well as keywords, contain _all_ of the information in their alphanum
names. The surrounding crutches for low capability parsers give nothing to
the user.
Erik
--
> Am I correct that perl5-porters is the proper forum for submitting
> my ideas?
I think you didn't get a reply because you used the terms "correct" and
"proper", neither of which has much meaning in Perl culture. :-)
-Larry Wall
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
