Re: LL Parser problem

"Nick Roberts" <nick.roberts@acm.org> schreibt:


>I didn't mean to suggest that parser generators are losing their
>relevance, but rather that /limited grammar/ parser generators are
>losing their relevance (compared to backtracking parser generators,
>whose grammars are not limited, as such).


I wonder what such parser generators are good for?


Wouldn't it be much better do design a simple and robust language and
grammar in the first place, instead of assuming that "there will be
some parser that can figure out my sh**"? Where in former times a
handcrafted parser was written, without a grammar and in spaghetti
code technology, nowadays the spaghetti coding mentality is applied to
grammars :-(


IMO many problems could be solved by a redesign of weak syntax, like
for XML and C. Why has a parser to know about type names for proper
operation (C), when other languages are LL(1) and don't require any
context information while parsing?


OTOH I'm still waiting for an parser for machine code, that can not
only separate executable code into instructions, but furthermore will
structure the instructions into statements, loops, methods and
classes. This were one of the few exceptions where I admit that we
have to live with a given grammar.




My strongest argument for really context free grammars, best LL(1), is
the chance for a complete separation of the grammar and parser from
any implementation language. Nowadays grammars require the insertion
of syntactic and semantic code into the mere grammar, when a parser
for a language shall be created. When instead a parser could be
constructed from a grammar without any additional code, the separate
maintenance of the grammar and the intended application (compiler...)
would be much easier. Then the parser could create an parse tree, or
some other suitable meta data structure, based on nothing but the
grammar, and the application only had to deal with that well defined
and language independent information.


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.