Re: Calling a parser from a parser

[Hans Aberg]

on 2004/10/27 18:17, Frank Heckenbach at address@hidden wrote:

>> There is in fact a situation where one writes a parser within a parser, and
>> that is the case when the inner parser is dynamic in a way that it cannot be
>> handled by the outer parser. This happens, for example, when the grammar has
>> a large number of precedence levels (as in say Pascal): One can then let the
>> outer parser just collect the tokens into a sequence, and let another parser
>> sort out the semantics by the use of the precedence levels. In a language
>> with just a few precedence levels, like Haskell, which only has ten, one can
>> do it either way: Use this method, or write a .y section for each precedence
>> level.
> 
> I really don't know what's it with you and Pascal, but just FYI,
> Pascal has only 5 levels of precedence:

It is a typo, of course. It should be Prolog, in which operators can
dynamically be assigned a precedence integer in the range [1, 1200].

> parentheses
> exponentiating-operator
> multiplying-operator
> adding-operator
> relational-operator
> 
> Some dialects may have one or two more, but that's still quite a bit
> less than C (which has 15 according to gcc's grammar) or Haskell (10
> according to you).

As for Pascal, it is a well known design flaw of that language to give it
too few precedence levels, forcing the user to put in a lot of parenthsises
where it feels unnatural to do so. C is in this respect a great improvement
over Pascal.

> Apart from that, why do you think that a simple parser couldn't
> handle even many more levels of precedence? In fact, that's one of
> the strengths of LALR(1), and the canonical examplel are of this
> kind.

I hope I made clear that for the ambitious, one can write in the 1200 x
(number of operator types) rules needed for implementing Prolog this way
statically in Bison. Others may feel that a bit tedious. Or how would you do
it?

By the use of a nested parser, I wrote an extension admitting even more
levels, 2^32, I think (the exact number is irrelevant, once one goes
dynamic). Then it starts to become quite impossible to handle that
statically. I am now thinking of an even more advanced operator system,
making use of (dynamic) SLR(1) or LR(1); then it becomes truly impossible to
handle that statically within Bison.

  Hans Aberg