Re: Ordering in `source' property, and auto-loading of c-lang-defconsts

[Alan Mackenzie]

Hi, Stefan.

On Thu, Aug 28, 2014 at 10:09:13AM -0400, Stefan Monnier wrote:

> I'm trying to understand some of cc-defs.el and cc-langs.el code and
> while there are very many questions, I'll stick to a fairly limited subset
> for now.  Hopefully once that's cleared, it'll be easier for me to guess
> what the rest is about:

If you haven't already done so, I'd recommend M-x load-file cc-langs.elc,
then typing something like the following into *scratch* and evaluating it
after byte-compiling various cc-files.el:

(let ((sym (intern "c-identifier-start" c-lang-constants)))
  (list
   (symbol-name sym)
   (symbol-value sym)
   (symbol-plist sym)
   ;; (symbol-function sym)
   ))

> - What the relationship between the `source' property and the
>   `symbol-value' of the symbols that are in the c-lang-constants obarray?

The `source' property holds a cons of the source file (as a symbol, e.g.
`cc-langs') and the source code of the c-lang-defconst (somewhat
processed for uniformity by c-lang-defconst).

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).

> - 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.

> - It seems that the `source' property contain an list of (FILE . LANG-ALIST)
>   entries (where each LANG-ALIST is a list of (MODES . CODE)).  Right?

Yes.

> 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.

> 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.

> .... so there's only ever a single FILE there and it never needs to be
> (auto)loaded.  But even for modes distributed separately [BTW, it'd be
> good to try and keep track of them to some extent, which reminds me I
> should do the same for SMIE], I don't see why ordering is important (I
> mean I understand why ordering is important w.r.t the derivation
> hierarchy, but not w.r.t FILEs) nor in which circumstance you'd already
> know about the existence of a call to c-lang-defconst in some FILE yet
> that FILE isn't loaded yet (i.e. why/when would you know and need to
> (auto)load FILE from c-find-assignment-for-mode)?


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).