From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4497 invoked by alias); 30 Mar 2010 22:20:16 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 4477 invoked by uid 22791); 30 Mar 2010 22:20:13 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Message-ID: <4BB27911.9020000@redhat.com> Date: Tue, 30 Mar 2010 22:20:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc11 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Project Archer Subject: Re: Parser rewritting References: <201003301546.34866.sergiodj@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2010-q1/txt/msg00101.txt.bz2 On 03/30/2010 02:18 PM, Tom Tromey wrote: > Also, there is no good way in bison to disable a production only when > the parsing language is C++. You can play games by returning different > tokens in different modes, or you can run a preprocessor on the grammar, > but both of those are pretty ugly. Do we really need to worry about C vs C++? How dangerous would it be to simply assume C++? [I know there is a subtle difference between the two, I just wonder whether it would matter that much in usage to warrant treating the two differently/independently.] I also worry more about three other areas that might influence design/implementation decisions: 1) Java? Okay, we could probably work around this by using the current parser for java (ick!) [Do we even consider adding java to the mix worth it? I don't, but that's just my opinion...] 2) Linespec re-evaluation: Let's face it, a number of us have had to deal with problems in linespec.c, and we all know it's a nightmare. Anyone (else) interested in moving to expressions-based linespec processing? 3) Symbol table cleanups: I get a sinking feeling that the symbol table API may need some work before any attempt at writing a new parser my be started. Specifically, when a symbol lookup happens, we should get ALL matching symbols, not just the first one found. [Maybe that's just me?] I know this was a constant barricade when trying to implement overload resolution in the parser. And to this day, we cannot implement overload resolution on a non-class function. A nice side-effect of this: it would help with symbol completion. Heck, I might even just settle for something that says there are multiple matches... Keith