From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29069 invoked by alias); 10 Apr 2012 21:29:53 -0000 Received: (qmail 29056 invoked by uid 22791); 10 Apr 2012 21:29:52 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Apr 2012 21:29:35 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3ALT9tj009298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 17:29:09 -0400 Received: from [10.36.5.101] (vpn1-5-101.ams2.redhat.com [10.36.5.101]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3ALT6DT007184; Tue, 10 Apr 2012 17:29:06 -0400 Subject: Re: Switching to C++ by default in 4.8 From: Torvald Riegel To: Eric Botcazou Cc: gcc@gcc.gnu.org, Michael Matz , Xinliang David Li , Jakub Jelinek , Richard Guenther , Bernd Schmidt , Gabriel Dos Reis , David Edelsohn , Diego Novillo In-Reply-To: <201204102312.37159.ebotcazou@adacore.com> References: <4F7B356E.9080003@google.com> <201204101959.33888.ebotcazou@adacore.com> <1334087757.11195.75.camel@triegel.csb> <201204102312.37159.ebotcazou@adacore.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 Apr 2012 21:29:00 -0000 Message-ID: <1334093345.11195.87.camel@triegel.csb> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg00370.txt.bz2 On Tue, 2012-04-10 at 23:12 +0200, Eric Botcazou wrote: > > Or are you really saying that the number of characters determines how > > quickly/easily a brain can remember/find something like an API > > item/keyword/...? If so, and if we assume that GET, FIELD, and DECL are > > the most likely (sub-)parts of function names shouldn't it be G_F_D > > (exp) then? ;) > > The number of tokens. GET_FIELD_DECL has 2 tokens (GET and FIELD_DECL) while > exp->as_component_ref().get_field() has 3x more. I can't derive a definition of "token" from your example that seems meaningful. It can't be parser tokens I assume, because you split GET_FIELD_DECL (but why in 2 not 3?). Same for "exp->..."; where are the 8 tokens? (Or did you in fact mean 3 times as much, so 6?). In any case, that suggests that the tokenization you had in mind is not obvious (or perhaps just not to me). Following another comment in the thread, what are the concepts you'd like to be included, and which don't you want to be included? Next step, is this actually tied to saying FOO(exp) vs. exp->foo(), or could your favorite (compression of) concepts be as well expressed with the latter?