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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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/