[nem-en] [RFC] type parens

[Michal Moskal]

On Fri, Sep 24, 2004 at 07:33:34PM +0000, Kojo Adams wrote:
> 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.

Yeah, you're right. This kind of hack should work, but it's still a
hack... I especially don't like the:

>> The technique relies upon certain conventions that programmers use in C#. An
>> expression of the form "A < B > C" is unlikely to be "(A < B) > C" because C#
>> programmers don't normally compare boolean values with ">". If the
>> programmer did intend to use ">" to compare boolean values, then they will
>> need to add extra parentheses.

part.

[...]
> 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.

It would be nice to see it!

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: ::: Logic is a nice contrast to the Real World. :: UL++++$ C++ E--- a?