|Re: C++ intermediate representation. firstname.lastname@example.org (2005-05-15)|
|RE: C++ intermediate representation. email@example.com (Quinn Tyler Jackson) (2005-05-15)|
|Languages that are hard to parse firstname.lastname@example.org (Steve) (2005-05-16)|
|Re: Languages that are hard to parse DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-05-18)|
|Re: Languages that are hard to parse email@example.com (glen herrmannsfeldt) (2005-05-18)|
|Re: Languages that are hard to parse Peter_Flass@Yahoo.com (Peter Flass) (2005-05-19)|
|Re: Languages that are hard to parse firstname.lastname@example.org (glen herrmannsfeldt) (2005-05-20)|
|Re: Languages that are hard to parse DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-05-20)|
|Re: Languages that are hard to parse email@example.com (2005-05-21)|
|Re: Languages that are hard to parse firstname.lastname@example.org (glen herrmannsfeldt) (2005-05-22)|
|[9 later articles]|
|From:||Hans-Peter Diettrich <DrDiettrich@compuserve.de>|
|Date:||18 May 2005 00:49:24 -0400|
|References:||05-05-119 05-05-125 05-05-147|
|Posted-Date:||18 May 2005 00:49:24 EDT|
> Are you saying that designing hard to parse languages is a good thing?
*How* are languages designed?
IMO new programming languages are designed for easy parsing, by using
either a grammar based parser generator, or in handwritten code
without a (proven) grammar. Derivates of "un-formal" legacy languages,
like C, fall into their own category (homebrew trouble, dead end ;-)
So the question is not about "hard to parse", instead it should read
"formal design - yes or no".
In so far it's a good idea to provide parser generators with the best
possible support for grammar analysis, so that, in the ideal case,
nobody will ever more try to write an handcrafted parser for his
AFAIK even a good grammar analyzer cannot determine whether a language
is ambiguous - at least not for higher level grammars. This would mean
to restrict future parser generators to grammars that can be formally
verified. The parser generation then is less important, as long as the
user will know that a big or slow parser is the result of his own
misdesign, and does not indicate an poor parser generator whose output
deserves manual optimization.
For derivates of C, or other legacy languages, I'd suggest an source
code converter that can translate all legacy code into a simpler and
more formal language, and to restart language evolution from that base.
In so far I feel no need or reason for more sophisticated parser
generators. But, as Quinn Tyler Jackson explained to me, there exist
more than only programming languages. The existence of natural languages
should be obvious, less obvious are other natural phenomenons of
possibly "formalizeable" nature. This is a vast area for parsing
techniques and translator generators, be new or already under
development. Appropriate tools should allow to express a "feeling for
some underlying order" in a formal way, and to subsequently verify the
language design by feeding a test suite into the created parser. In such
cases again the question is not about "hard to parse" languages, it's
only a question of what's feasable at all. Context sensitive or possibly
irregular languages deserve new descriptive formalisms, not covered by
traditional (BNF...) grammars and tools.
Return to the
Search the comp.compilers archives again.