On 29.01.12 11:14, Kent A. Reed 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.
>
> Whatever qualms I may have about the difficulty of interjecting 
> meaningful error messages into an interpreter based on lex'ing and 
> parsing is overcome by the benefits you point out here.

It's good to talk this stuff over then, because we then all have a
better understanding of where we can get to from here, with manageable
effort and useful improvement. (I.e. "The perfect is the enemy of the
good.") I just don't know how to generate enthusiasm for a decluttered
amateur-readable syntax which helps us dilettantes up the gcode learning
curve. (As a 30-year programming veteran, I can't hack going back to the
days when we didn't even have an assembler to convert human-readable
mnemonics to the meaningless machine code. There's no difference between
"0x01" and "G01" in terms of human-readability.)

Error messages can be made meaningful to an experienced user of a tool.
They cannot remove the learning curve which a newcomer to the discipline
must climb, I find. I've seen some unreasonable expectations expressed
by new users, when the primary problem was that they did not understand
that they need to understand the language they're using, and make some
inferences from the hints provided by a translation tool which is not a
tutor. (Well, especially not when it's in beta.)

When developing language translators, I usually have implemented basic
translation, followed by low-hanging (i.e. easy to implement) error
messages, then trickier translation, and finally less obvious error
messages. The latter may continue to be added throughout the life of the
product.

Erik

-- 
Note that this is Perl code and I'm well-aware of the general "unparseable"
nature of Perl. A "most works" solution would be fine.
                                                  - Ovid, on Vim Users ML.


------------------------------------------------------------------------------
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

Reply via email to