From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: Ordering in `source' property, and auto-loading of c-lang-defconsts Date: Sun, 31 Aug 2014 20:52:40 -0400 Message-ID: References: <20140831212355.GA4401@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1409532803 29447 80.91.229.3 (1 Sep 2014 00:53:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Sep 2014 00:53:23 +0000 (UTC) Cc: Alan Mackenzie , Martin Stjernholm , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Mon Sep 01 02:53:17 2014 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XOFrv-0000s5-Hm for sf-cc-mode-help@m.gmane.org; Mon, 01 Sep 2014 02:53:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-2.v29.ch3.sourceforge.com) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XOFrm-0008SV-5T; Mon, 01 Sep 2014 00:53:06 +0000 Original-Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XOFrk-0008SP-Qu for cc-mode-help@lists.sourceforge.net; Mon, 01 Sep 2014 00:53:04 +0000 Received-SPF: softfail (sog-mx-3.v43.ch3.sourceforge.com: transitioning domain of iro.umontreal.ca does not designate 208.118.235.10 as permitted sender) client-ip=208.118.235.10; envelope-from=monnier@iro.umontreal.ca; helo=fencepost.gnu.org; Original-Received: from fencepost.gnu.org ([208.118.235.10]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1XOFrj-0007ao-HQ for cc-mode-help@lists.sourceforge.net; Mon, 01 Sep 2014 00:53:04 +0000 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51511) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1XOFre-0008GQ-10 for bug-cc-mode@gnu.org; Sun, 31 Aug 2014 20:52:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOFrT-0007lu-CE for bug-cc-mode@gnu.org; Sun, 31 Aug 2014 20:52:57 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW autolearn=disabled version=3.3.2 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:4882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOFrT-0007kQ-7l; Sun, 31 Aug 2014 20:52:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNFxLul/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kCod6CNIZF456B4Q4BJRilDeBaoNMIQ X-IPAS-Result: ArUGAIDvNVNFxLul/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kCod6CNIZF456B4Q4BJRilDeBaoNMIQ X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="88336900" Original-Received: from 69-196-187-165.dsl.teksavvy.com (HELO ceviche.home) ([69.196.187.165]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2014 20:52:40 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 6CE88660C4; Sun, 31 Aug 2014 20:52:40 -0400 (EDT) In-Reply-To: <20140831212355.GA4401@acm.acm> (Alan Mackenzie's message of "Sun, 31 Aug 2014 21:23:55 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) X-Headers-End: 1XOFrj-0007ao-HQ X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:6432 gmane.emacs.devel:173937 Archived-At: Thanks, Alan. > The symbol-value is an alist of elements which look like, e.g., (c-mode . > "[[:alpha:]_]"), there being a separate element for each language. It is > generated by byte-compiling cc-mode.el, and contains the final value of > the c-lang-defconsts, used in generating the c-lang-defvars (which are > ordinary variables in the standard obarray). Right, in the mean time I figured this part, indeed. t doesn't hold "the final alist" but rather "an alist of final values" (i.e. only contains the final value for those major modes for which it's been computed). Basically, we evaluate those values lazily and memoize the result in these alists. >> - Do those symbols hold other information (I don't see another property >> being used, nor does the symbol-function slot seem to be used, but >> maybe I just missed it)? > The symbol-function is not used (there is no occurrence of > "symbol-function" in cc-defs.el). Some other properties stored in the > obarray are `variable-documentation' and `dependents', the latter being a > list of `c-lang-defconst's which use the current `c-lang-defconst' (the > list can contain the current `c-lang-defconst' "recursively"). I don't > think there are any more. Ah, yes, I see it now, thanks. It seems the `variable-documentation' property is only used to transfer the docstring from the c-lang-defconst to a corresponding c-lang-defvar. And the `dependents' seems to be only used to track which vars need to be recomputed (which part of the memoization table needs to be flushed) when a c-lang-defconst is re-evaluated (I guess typically be M-C-x or by re-loading cc-langs, so it's really only used for development purposes). >> Here's the main question: >> - Why is this FILE needed? Why is it important to preserve ordering >> between various FILEs? Why do we sometimes `load' those FILEs (in >> c-find-assignment-for-mode)? Which kind of concrete situation is this >> supposed to address? > I'm not unconfused enough to say. Sorry. But it seems it will have to > do with modes derived from CC Mode using c-add-language. I'm trying to > work out why we need to load the source files when all the information is > already contained in the c-lang-constants obarray. I can't figure out when we'd (auto)load a file based on this FILE info. OTOH I did figure out why we otherwise need this FILE info: if a "c-lang-const" is defined by various c-lang-defconst (as is the case if you have an unbundled amjor mode that uses the CC-mode engine), this lets you correctly handle the reloading of a file that calls c-lang-defconst, only replacing the part of the definition that this file had provided. So again (like `dependents') this seems to be mostly useful for development purposes. >> My vague understanding is that we want to allow c-lang-defconst to be >> called (for the same variable) from different files for different >> major modes. Of course, for those modes supported natively by CC-mode, >> they're all in cc-langs.el ..... > There are some c-lang-defconsts in cc-fonts.el. Thanks for the heads up, I hadn't noticed them. I'll take a look (tho expect it won't make much difference in the sense that these vars are still defined in only one file for the bundled code. I.e. the `source' property is still a single-entry list). Looking at `source-pos', I think I see one reason why ordering matters: in order for the definition of a variable to be able to refer to the definition of that same variable but in its parent major-mode, it is necessary for the two definitions to appear in the right order. This is not inherent, but is an artifact of the way the lookup is done to try and make it work without bumping into an infinite cycle. If my analysis is right, then I think I see a way to make it a bit more robust and cleaner, getting rid of those ordering constraints. Stefan ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/