From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30387 invoked by alias); 25 Oct 2004 23:53:21 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 30213 invoked from network); 25 Oct 2004 23:53:20 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 25 Oct 2004 23:53:20 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i9PNwJaU023992 for ; Mon, 25 Oct 2004 16:58:19 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Mon, 25 Oct 2004 16:53:23 -0700 Received: from [17.219.198.213] ([17.219.198.213]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i9PNrG1N019142; Mon, 25 Oct 2004 16:53:17 -0700 (PDT) Message-ID: <417D91EB.2080504@apple.com> Date: Tue, 26 Oct 2004 00:03:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: "Joseph S. Myers" CC: Ziemowit Laski , gcc-patches@gcc.gnu.org Subject: Re: New C parser [patch] References: <42A6DEB0-26D4-11D9-9558-000D9330C50E@apple.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg02134.txt.bz2 Joseph S. Myers wrote: >On Mon, 25 Oct 2004, Ziemowit Laski wrote: > > >>I'm just curious as to why you think that writing a C parser from scratch is >>easier than tweaking Mark's parser to handle C. >> > >You have an interesting definition of "tweaking". Geoffrey Keating gave >an estimate of 6-9 man-years to merge the front ends making them handle >the present languages as fast as at present. This compares to 1 man-week >to write a functional C parser for the exact present language accepted >which also speeds up the compiler despite not having been profiled or >tuned for performance at all. > To be fair though, Geoff's estimate accounted for merging a lot of the semantic processing that continues to be semi-clones of each other, and continues to cause performance problems that have to be solved twice. Even so, changing to a recursive descent parser is a step in the right direction, because it will be easier to compare with the C++ parser. And of course it's awesome that you did it in a week; if you can do it that quickly, maybe it would only take you a couple months to merge frontends! :-) >>I'm asking because merging the front-ends would allow ObjC/ObjC++ to be >>simplified _tremendously_: we will be able to utilize C++ machinery >>to implement ObjC subclassing and access control, not to mention a >>more sensible interaction of ObjC objects with C++ EH and RTTI. >> > >Merging front ends provides only marginal maintenance benefits - a great >many changes to a merged front end would need to consider their possible >effects on many more different languages and language versions than at >present, making the burden associated with making each change that much >greater though maybe slightly reducing the number of changes to be made. >C and C++ have been diverging for over 20 years; many similarities are >only superficial and hide underlying differences and are dangerous to rely >on if you want a correct compiler. > > As I understand it, the C/C++ divergence is not something that anyone really wants - not the language committees, not implementors, and most especially not users, who just don't buy any of our explanations - their atttitude is "You control the languages and the compilers, who's stopping you from solving the problem!?". One of the things I think we could be doing for the users is to exert our influence on language committee people to cooperate better than they have been, and to lead by example, in the way that GCC is implemented. The attitude that C and C++ are diverging, and so we might as well go along, seems kind of defeatist, and will just encourage more of the very things that we don't want to happen (just imagine further divergence requiring two different preprocessor libraries - bleah!). Stan