From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Fri, 09 Jan 2015 10:36:08 +0200 Message-ID: <83iogg5p1j.fsf@gnu.org> References: <83bnxuzyl4.fsf@gnu.org> <8761nusb90.fsf@uwakimon.sk.tsukuba.ac.jp> <87vbkovhh7.fsf@engster.org> <87387rvobr.fsf@engster.org> <83ppat84hk.fsf@gnu.org> <20150106143933.0090bc83@jabberwock.cb.piermont.com> <83r3v77ij6.fsf@gnu.org> <20150106154539.3d0752c4@jabberwock.cb.piermont.com> <87wq4ype3z.fsf@fencepost.gnu.org> <878uherlf3.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1420792839 27864 80.91.229.3 (9 Jan 2015 08:40:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Jan 2015 08:40:39 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 09 09:40:32 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y9V3E-0003zW-5d for ged-emacs-devel@m.gmane.org; Fri, 09 Jan 2015 09:36:12 +0100 Original-Received: from localhost ([::1]:49500 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9V3D-0007aH-H3 for ged-emacs-devel@m.gmane.org; Fri, 09 Jan 2015 03:36:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9V2z-0007aC-0N for emacs-devel@gnu.org; Fri, 09 Jan 2015 03:35:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9V2v-0003sa-PU for emacs-devel@gnu.org; Fri, 09 Jan 2015 03:35:56 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:41053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9V2v-0003sW-HO; Fri, 09 Jan 2015 03:35:53 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NHW00I00I6TCT00@a-mtaout20.012.net.il>; Fri, 09 Jan 2015 10:35:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHW00IF2IJRAB40@a-mtaout20.012.net.il>; Fri, 09 Jan 2015 10:35:51 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:181092 Archived-At: > Date: Thu, 08 Jan 2015 18:59:24 -0500 > From: Richard Stallman > Cc: emacs-devel@gnu.org > > > auto some_var = foo(bar); > > > and when the compiler resolves `foo' it can choose an overload depending > > on complex attributes of `bar' (such as if `bar' is an instance of a > > class that implements certain method.) As each overload can return a > > different type, only a C++ compiler can know which type `some_var' > > finally is. > > To handle that, it is sufficient that the compiler say what type > some_var was ultimately given. Of course, the data must include > the data types of all identifiers. A single source line can reference more than one identifier that have the same string as their name, but different semantics and types. A list of all the identifiers and their types is not enough to handle that; you need to know the type of each 'foo' in its exact place. Even in C, a single string can mean very different things in the same program unit, due to different namespaces, like variables/functions vs struct tags vs struct members vs labels. Further, to support refactoring, one needs to have access to the semantics of arguments of each function, otherwise the refactored code will fail to compile at best and introduce subtle bugs at worst. The list of identifiers and data types won't be enough here as well. > Some data that I am sure is NOT needed is the entire statement-level > structure. I suggested to write down requirements for what _is_ needed. I suspect that the full amount of syntactic and semantic information that is needed for the features we are discussing is very close to the AST. After all, what other ways are known to mankind for expressing this kind of information? Since no one seems to be willing to bite the bullet, how about the list of features, such as completion and refactoring, that we would like to enable? Would someone who feels they know enough about this please post such a list, with a short (1-2 sentences) description of each feature? The reason I think such a list would be useful is that I'm not sure Richard is aware of the kind of features we are talking about, which makes this discussion less efficient and effective than it could be.