Re: Parser rewritting

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:

Keith> Do we really need to worry about C vs C++? How dangerous would it be
Keith> to simply assume C++? [I know there is a subtle difference between the
Keith> two, I just wonder whether it would matter that much in usage to
Keith> warrant treating the two differently/independently.]

There are plenty of unsubtle distinctions as well, like all the
additional operator names in C++.  This we have to handle, though of
course we already have an adequate solution here.

Offhand I don't know if there are productions which would cause
confusion if enabled in C.  Maybe not.  It still seems less potentially
confusing and perhaps mildly more future-proof to follow each language
spec relatively closely.

Keith> 1) Java? Okay, we could probably work around this by using the current
Keith> parser for java (ick!) [Do we even consider adding java to the mix
Keith> worth it? I don't, but that's just my opinion...]

Let's leave Java alone.  It is "good enough" and really reworking it
isn't our mandate.

If we were going to really consider merging another language into this
effort, I would say ObjC, which currently has its own fork of c-exp.y,
minus most of the bug fixes from the last couple of years.  But even
there, I would rather have somebody knowledgeable and interested in ObjC
do it.

Keith> 2) Linespec re-evaluation: Let's face it, a number of us have had to
Keith> deal with problems in linespec.c, and we all know it's a
Keith> nightmare. Anyone (else) interested in moving to expressions-based
Keith> linespec processing?

Yeah, I think we need a better parser in linespec.c, but I see that as
mostly orthogonal.  Maybe we would need a second entry point to each
language's expression parser to let us ask for just a "function name"
production, but otherwise I don't think there is a big overlap.  This
can easily be retrofitted into the bison-based parsers if needed.

Keith> 3) Symbol table cleanups: I get a sinking feeling that the symbol
Keith> table API may need some work before any attempt at writing a new
Keith> parser my be started.

Keith> Specifically, when a symbol lookup happens, we should get ALL matching
Keith> symbols, not just the first one found. [Maybe that's just me?]

I tend to agree with this idea, though I haven't thought through all the
ramifications.

But this can also be done independently, I think.  The overload
resolution stuff is largely done at evaluation time, not in the parser
(which makes sense if you want to choose different overloads depending
on the value of a convenience variable, which doesn't have a static
type).  So here we would need the symbol table change and perhaps an IR
change -- but not, I think, a parser change.

IMO, the first goal for a rewrite of the parser should just be feature
parity.  It is just changing how we express the parser, from bison to
(say) recursive descent.  Then we can start adding features, fixing
bugs, and moving hacks out of the lexer and into the parser.

Tom