Is it LL(1)? Can it be converted to LL(1)?
Thanks

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:bgntfi$qhg$1@digitaldaemon.com...
> Is it LL(1)? Can it be converted to LL(1)?

No, it requires arbitrary lookahead.

I know I'm asking stupid questions:
I like D very much and i would like to write a parser for it (for fun).
Does arbitrary lookahead mean LR(1) grammar/parser?
Im writing a program that creates a LR(1) parser table from the grammar
but i would like to know is LR(1) the right parser?

"Walter" <walter@digitalmars.com> wrote in message news:bgon6j$1kfd$2@digitaldaemon.com...
>
> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:bgntfi$qhg$1@digitaldaemon.com...
> > Is it LL(1)? Can it be converted to LL(1)?
>
> No, it requires arbitrary lookahead.
>
>

Walter wrote:
> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message
> news:bgntfi$qhg$1@digitaldaemon.com...
> 
>>Is it LL(1)? Can it be converted to LL(1)?
> 
> 
> No, it requires arbitrary lookahead.
> 
> 

Hi, Walter.

What parts require arbitrary lookahead?  Being able to YACC D seems a worthy goal.

Bill

Bill Cox wrote:
> Walter wrote:
> 
>> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message
>> news:bgntfi$qhg$1@digitaldaemon.com...
>>
>>> Is it LL(1)? Can it be converted to LL(1)?
>>
>>
>>
>> No, it requires arbitrary lookahead.
>>
>>
> 
> Hi, Walter.
> 
> What parts require arbitrary lookahead?  Being able to YACC D seems a worthy goal.

Distinguishing locals declarations and C-style casts from expressions.

Bill Cox wrote:
> Being able to YACC D seems a worthy goal.

What for? YACC is past and even "considered harmful"! New Bison supports GLR. There are tons of other GLR and LL(inf) parser generators out there.

-i.

Ilya Minkov wrote:
> Bill Cox wrote:
> 
>> Being able to YACC D seems a worthy goal.
> 
> 
> What for? YACC is past and even "considered harmful"! New Bison supports GLR. There are tons of other GLR and LL(inf) parser generators out there.
> 
> -i.
> 

Hi, Ilya.

Support for GLR in Bison is quite new.  It wasn't in the general release last year.  Also, there's a performance penalty to use GLR.

I strongly encourage anyone making a new language format to create a machine verified version, whether it uses GLR or LR(1).

Until the rules have be verified by a parser generator, you can bet the rules are wrong.

Bill

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:bh0jct$30ml$1@digitaldaemon.com...
> Bill Cox wrote:
> > Being able to YACC D seems a worthy goal.
>
> What for? YACC is past and even "considered harmful"! New Bison supports GLR. There are tons of other GLR and LL(inf) parser generators out there.
>
there may be, but none will create D code .... Antlr does C++ and Java and I
believe it can rebuild itself (am looking for somewhere to get it
www.antlr.org seems to be missing! so might be able to squeeze a D version
out of it.
I don't fancy trying to port Bison to D.
Antlr also allows tree walkers to be defined which is very useful (LALR and
LL(n) only I believe)

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:bgvq53$28sd$1@digitaldaemon.com...
> I know I'm asking stupid questions:
> I like D very much and i would like to write a parser for it (for fun).
> Does arbitrary lookahead mean LR(1) grammar/parser?
> Im writing a program that creates a LR(1) parser table from the grammar
> but i would like to know is LR(1) the right parser?

I can never remember the difference between LL, LR, LALR, etc., probably because I never use parser generators. But it is not (1) because it requires arbitrary lookahead, mostly in trying to figure out if a sequence of tokens is a type or an expression, declaration or statement.

The parser (parse.c) is set up to make lookahead easy.

Walter wrote:
> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message
> news:bgvq53$28sd$1@digitaldaemon.com...
> 
>>I know I'm asking stupid questions:
>>I like D very much and i would like to write a parser for it (for fun).
>>Does arbitrary lookahead mean LR(1) grammar/parser?
>>Im writing a program that creates a LR(1) parser table from the grammar
>>but i would like to know is LR(1) the right parser?
> 
> 
> I can never remember the difference between LL, LR, LALR, etc., probably
> because I never use parser generators. But it is not (1) because it requires
> arbitrary lookahead, mostly in trying to figure out if a sequence of tokens
> is a type or an expression, declaration or statement.
> 
> The parser (parse.c) is set up to make lookahead easy.
> 
> 

Hi, Walter.

I believe LR(1) is what YACC does (maybe it's LL(1)).

YACC has some abilities to look ahead.  It pushes "unreduced" tokens on the token stack, and waits for a rule to be able to reduce them.  I doubt D's type declarations are a problem.  Generally, grammers become non-YACC friendly when parsing depends on context information.  For example, foo(bar) in an expression can be a function call, or a cast expression in C++.  You can't build a reasonable data structure for it when you read it, and instead have to come back later and patch it.

From what I've seen of D, the grammer looks YACC friendly.  I could be talked into verifying this, if you could create a text file of BNF rules for D.

Bill