[nem-en] [RFC] type parens

[Kojo Adams]

Hi,
>This is somewhat related, but different issue. This is about yacc
>parsers. We're not going to use yacc -- there will be two level, hand
>written parser. However the second part is going to be parametrized with
>user-defined rules, that will hopefully provide more flexible ways of
>extending the parser, then the current solutions.

I could be wrong but what I understood from his response was that deciding 
whether a '<' seen is for a comparison (LT) or for a type (GENERICS_LT) is 
done by the lexer and so the parser does not need to worry about it. gmcs 
seems to something similar. I just took a quick look at the source code.

>As a side note, the solution Rhys choose seems quite hackish, and is of
>the kind I would like to avoid in Nemerle.

I agree this is ugly code.

Btw I wrote a lexer generator in nemerle and am trying to write a parser 
generator too. The lexical analysis generator stilll has some bugs to iron 
out but it works well on small files. Is anyone interested in this code. It 
is not very clean code but it works.

Kojo

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail