On 30.01.12 12:37, Kent A. Reed wrote:
> On 1/30/2012 7:54 AM, Kenneth Lerman wrote:
> I would hope for
>
> 1) a formal description of the grammar we already have. As Erik points
> out, the LinuxCNC interpreter implicitly defines a grammar. It's just
> hard to tell what the grammar is. It's hard to talk about the language
> without a description of it, and as some of Erik's requests have
> illustrated, the current description is cryptic. If the only outcome of
> the current activity is to come to agreement on this description, I will
> consider it a step forward.
If others will instruct me in what's legal syntax for any command, then
I'll formalise that in a BNF grammar. (We could look at the sample gcode
grammars on the web, but they're not ours. (And I have to get ready to
go out to dinner tonight, so can't look just now.))
Over a couple of months, we should be able to work out what we believe
the LinuxCNC parser wants to see.
> 2) a means to express and maintain the grammar in machine-processable
> form. Looking at and maintaining text is a bore.
BNF is the most universally comprehended, easy to read, and tools can
generate code from it.
> 3) tools that allow one to treat the grammar as an engineering object,
> e.g., view it, analyze it, manipulate it (refactor, group, etc), and
> extend it. This area was an arid desert the last time I did any related
> technical work.
Well, BNF does that, and being more lexically inclined than visually,
I'll admit to doing that sort of stuff for fun.
> 4) tools like lex/yacc (flex/bison), antlr, etc., that can take this
> same machine-processable form and generate all the software goodness
> we've talked about.
...
> Note that all of this is just ground work that I would hope gets done in
> advance of all the other topics that have been mixed into this thread
> such as simplified syntax, conversational coding, etc.
Yes, that's a wise goal. But it is easy for a parser to make the "#< >"
stuff optional, so that users can put it in or omit it, according to
taste. That might help keep us motivated, because we can then use it as
a filter which provides a benefit beyond documentation.
> Note also that it can became an endless academic exercise if not kept
> in leash (I came across a 2011 presentation entitled "Why program by
> hand in five days what you could spend five years of your life
> automating?")
In 30 years of software development, I often had team members developing
custom tools (including custom compilers for our own state-machine
languages), and they always allowed us to finish projects faster, and
well within schedule. The very first one blew the socks off colleagues
in Munich, when they gave me telecommunications call-control protocol
changes daily at 9 a.m., and I had the software rejigged by lunch time,
every day. They could then test it in the afternoon. (It was a tiny
compiler which understood the problem-domain language used by the
protocol designers which did most of my work for me. After I'd written
it.)
If you do it right, often with tools you've written yourself, then tools
are the jet fighter of software development.
> And, finally, much of this has already been said by you and others.
> Let's just say we're in violent agreement.
Yes. It's just the length of the journey, the path to be taken, and just
precisely where we stop, that's subject to clarification. ;-)
Erik
--
"What is wanted is not the will to believe, but the will to find out,
which is the exact opposite."
- Bertrand Russell, _Sceptical_Essays_, 1928
------------------------------------------------------------------------------
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
