Re: Why are ambiguous grammars usually a bad idea? Why are languages usually defined and implemented with ambiguous grammars?

From	Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
Newsgroups	comp.compilers
Subject	Re: Why are ambiguous grammars usually a bad idea? Why are languages usually defined and implemented with ambiguous grammars?
Date	2021-12-29 16:05 -0800
Organization	Compilers Central
Message-ID	<21-12-020@comp.compilers> (permalink)
References	<21-12-003@comp.compilers> <21-12-017@comp.compilers>

Show all headers | View raw

On Wednesday, December 29, 2021 at 11:28:34 PM UTC+1, Kaz Kylheku wrote:
> On 2021-12-16, Roger L Costello wrote:
> > Question: Opine about why languages are usually defined and implemented with
> > ambiguous grammars.
> But they aren't.
>
> Languages are processed as a stream of characters or tokens, with hidden
> rules about how those relate together and the meaning that emerges.
> All of the rules are hidden, including the entire grammar.
>
> If you're only aware of some of the hidden rules, but not others, then
> you see ambiguity.
>
> But if you're only aware of some of the hidden rules, but not others,
> then you are not working with the correct language.
>
> For instance, I don't know of any mainstream language in which if/else
> is actually ambiguous. They have a hidden rule like that the else goes
> with the closest preceding if statement.

When designing a grammar and implementing a parser: the grammar can
either be unambiguous by design or unambiguous by accident. The
viewpoint that "there isn't any mainstream language in which if/else
is actually ambiguous" is actually the latter option: unambiguous by
accident.

A primary reason why grammars in many mainstream languages (that don't
have a parser generated straight from a verified grammar) are
unambiguous isn't intentional design, but rather it is a consequence
of the fact that those parsers are directly implemented in a language
that is executing statements/expressions/instructions without
verifying consequences of the executions. Some examples of languages
with such execution properties: assembly language (such as: i386,
ARM), C, Haskell. Contrary to the accidental approach, a parser
generator by design cares about consequences and it is verifying that
the specification actually is unambiguous despite the fact that in the
end the parser gets compiled down into machine instructions.
Verification means to search the whole search space (or at least a
reasonably large subspace of it) - but asm/C/Haskell will run a search
only if it is explicitly (step by step) forced by the programmer to
perform a search.

-atom

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

csiph-web