Related articles |
---|
[2 earlier articles] |
Re: A Grammar Writing Question cfc@shell01.TheWorld.com (Chris F Clark) (2007-07-26) |
Re: A Grammar Writing Question gah@ugcs.caltech.edu (glen herrmannsfeldt) (2007-07-26) |
Re: A Grammar Writing Question stephenhorne100@aol.com (Steve Horne) (2007-07-27) |
Re: A Grammar Writing Question DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-27) |
Re: A Grammar Writing Question cfc@shell01.TheWorld.com (Chris F Clark) (2007-07-28) |
Re: A Grammar Writing Question schmitz@i3s.unice.fr (Sylvain Schmitz) (2007-07-29) |
A Grammar Writing Question lowell@coasttocoastresearch.com (Lowell Thomas) (2007-08-07) |
From: | "Lowell Thomas" <lowell@coasttocoastresearch.com> |
Newsgroups: | comp.compilers |
Date: | Tue, 7 Aug 2007 10:40:53 -0400 |
Organization: | Compilers Central |
References: | <07-06-053@comp.compilers 07-07-081K |
Keywords: | parse, design |
Posted-Date: | 07 Aug 2007 15:55:43 EDT |
Thanks for all of the thoughtful comments. I think that they have
indicated an answer to the question but not quite in the way I
imagined when I asked it.
I was unaware of Jim Roskind's energetic and ingenious work am glad to
have had a look at it. But I don't think it provides an answer to the
question for a couple of reasons. 1) He says himself that the
disambiguation "if it can be a declaration, it is one" seems to
require a backtracking parser, which order-choice parsers are or at
least can be. And 2) it suggests, to me at least, that there is no
reason to believe that an equally energetic and ingenious effort on an
ordered-choice grammar wouldn't result in an equal or better match to
the C++ specification. When I look back on the situations where I have
had to re-write the grammar to shoehorn it into an ordered-choice
parser, I have usually looked to the specification or a set of
certified test strings for guidance and not worried much at all about
inaccessible fragments.
But more importantly, I think the question and the answer I was
looking for are too narrowly focused on the precise, mathematical
relationships among grammars, the languages they generate and the
parsers that process them. As important as they are (and as much as I
like tinkering with them) they are only part of the problem. I see at
least four parts to the overall problem: 1) the spoken word statement
of the language(the specification), 2) the generative grammar
statement of the language (usually acknowledged to not be quite be the
same as the specification), 3) the parsers that recognize the language
(usually approximations to the grammar used) and 4) the users of the
language. Once the language passes a certain, probably fairly low,
threshold of complexity, keeping these four aspects of the problem in
harmony, as C++ amply demonstrates, is the real challenge.
Why do I include the users of the language? Roskind found C++
statements that the designers hadn't anticipated and statements that
most compilers fail on through detailed, insightful hard work. But
take a look at the examples and ask yourself - if a compiler failing
on any of those examples was hanging up your project in a deadline
dash, would you be more inclined to replace the compiler or the
programmer whose coding practice just stumbled upon them?
I hope this isn't too much philosophizing, but this is what the
discussion brings up to the surface for me.
Lowell Thomas
www.coasttocoastresearch.com
Return to the
comp.compilers page.
Search the
comp.compilers archives again.