From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10958 invoked by alias); 31 Mar 2010 02:01:19 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 10753 invoked by uid 22791); 31 Mar 2010 02:01:16 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,SARE_MSGID_LONG40,TW_BJ X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: References: <201003301546.34866.sergiodj@redhat.com> <4BB27911.9020000@redhat.com> Date: Wed, 31 Mar 2010 02:01:00 -0000 Message-ID: <8ba6bed41003301901r1de5c99btc4941a84fdf7e643@mail.gmail.com> Subject: Re: Parser rewritting From: Matt Rice To: Tom Tromey Cc: Keith Seitz , Project Archer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2010-q1/txt/msg00103.txt.bz2 On Tue, Mar 30, 2010 at 3:59 PM, Tom Tromey wrote: >>>>>> "Keith" =3D=3D Keith Seitz writes: > > Keith> 1) Java? Okay, we could probably work around this by using the cur= rent > 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. =A0It 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. =A0But 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.