Re: Parser rewritting

[Matt Rice <ratmice@gmail.com>]

On Tue, Mar 30, 2010 at 3:59 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:
>
> 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.
>

I would agree with Tom, ObjC is a strict superset of C so it would be
alot easier to bolt on top of the new c parser.
and a unified parser could have good implications for myself,
having been debugging objc++ code, it is quite a pain to have to split
up expressions, and 'set language' in the middle of the split up
expression
so, i would be willing to put some time into getting objc working on
what you guys come up with, and keeping an eye on your progress with
this in mind.  not really something i'd expect you guys to undertake
just for fun

so first i need to start making test cases of the things the objc
parser currently handles,
then objc++ cases it doesn't currently handle

with any luck the differences between c and c++ will also be
applicable and adding objc support to the parser will not add
unforseen issues (I wont really hold my breath on that until i see
it...), if that is not the case, adding a 2nd set of problems now
won't get you guys any closer to your goal, while having the 1st set
of problems solved by your parser would surely help when dealing with
the 2nd set from the objc perspective.