Re: Avoiding 'reference to free variable' warningswhilesplittingelisp source files

["Andreas Röhler" <andreas.roehler@easy-emacs.de>]

Am 23.03.2013 23:41, schrieb Drew Adams:
>> Hmm... indeed.  That's too bad: it's really a misuse of the concept of
>> "definition": not only is it different from most other programming
>> language's use of "definition" and "declaration" but it's
>> also different from the everyday use of "definition".
>
> Not to belabor this ;-), but there is really no conflict with everyday use, IMO.
>
> One can distinguish defining something partially from defining it completely.
> You can decide to reserve the word "define" for defining completely.  Or not.
>
> (In my own view, all definition is partial in practice, if only because we can
> allow for redefinition in any context, and a complete definition would then mean
> over all time.)
>
> When you create something like a variable, which at runtime refers to a
> container/location that can optionally have contents/value, you _define_ it, at
> least partially.  At least in terms of everyday use of the word - IMO.
>
> Since the value is optional you might even consider that it is _fully_ defined
> without a value.  But at least one should accord that it is partially defined in
> that case.
>
> A variable is not the same thing as its value at a given time or even the same
> thing as its history of values over all time.  We agree about that, I expect.
> But people sometimes speak loosely of a variable being "undefined" when they
> really mean that its value is undefined.
>
> More generally, since it is a handy pointer and there is typically little risk
> of confusion, we often mistakenly speak about a variable when we really mean its
> value (at a given time).
>
> No real harm in that, in general.  It's a pardonable "misuse" of terminology -
> or a handy abbreviation, depending on your point of view.
>
> Whether a variable that has no known value is considered to be defined comes
> down to defining "define" for the given context (e.g. the given language, such
> as Emacs Lisp).
>
> There is nothing wrong with some language spec stating that by "undefined
> variable" it means a variable whose _value_ is undefined.  (Or that it means
> either that or else a variable that has never even been declared/mentioned.)
>
> On the other hand, there is nothing wrong with a language considering that such
> declarations are definitions.
>
> And that is the general tradition for Lisp: `defun, `defvar', `defconst',
> `defstruct', `defmacro',...  That little "def" prefix stands for "define".
> (Scheme even uses just `define'.)
>
> That's just naming, of course; it doesn't prove that these are actually
> definitions, according to some external criteria.  But it shows that Lisp and
> its original designers consider them to be definitions.
>
> You might consider all of that to be "misuse of the concept of 'definition."  I
> don't agree (though there is also room for multiple concepts of 'definition'),
> but it's not important.
>
> Someone could decide to revamp all of this in Emacs Lisp, for functions,
> structures, faces, and all the rest, preferring the term "declare" to "define"
> everywhere.
>
> Today, Emacs Lisp uses (you would say "misuses") "define" most everywhere, with
> the few exceptions I listed, most of which have specific meaning as
> declarations/suggestions to the compiler (and most of which are concerned with
> functions).
>
> But if you want to change to using "declare" everywhere instead of "define",
> have fun doing so.  Personally, I don't think you will gain much in the
> exercise.  (And it might even become harder to locate and talk about those
> compiler declarations we have today.)
>
>
> [There are also the various times/contexts of declaration/definition/creation to
> consider: in source code (for a human), in byte-compiled code (for tools), and
> in executing code (e.g. in memory).
>
> In one sense (for a human reader), just writing a variable
> declaration/definition declares/defines it.  In another sense, it is not
> declared/defined until a memory location is allocated for it at runtime.  In
> another sense, it is not fully defined until the content of that location has
> been filled explicitly by program (it always has some content).
>
> And then there are math variables as opposed to programming
> variables-as-locations.  But even for math (and functional language) variables,
> a text can talk about a given variable without its value being known.  Even
> there, the variable is something different from its value: it is a name for the
> value, just as the numeral `4' is a name for the number four.
>
> The only difference there from the usual programming case of a variable as a
> container with contents changeable over time is the changeable part.
>
> We still can talk about "defining" a variable (partially) when all that has been
> written so far is "Let X be an integer."  Naming is defining, at least to some
> extent.  Of course, "Let X = 2" is a more complete definition, and we do
> sometimes speak of X being "undefined" (an "unknown") in the first case.
>
> There is a lot of flexibility in the terminology, and yes, some misuse.]
>
>
>

Hi Drew,

let me take occasion to thank you of the numerous contributions making Emacs more user-friendly.
At the very case, as we may and must make an agreement how to understand words,
IMO Stefan's proposal is useful.

What about to understand "define" in a wider sense, making more comprehensive assigments, while
"declare" is understood as a beginning of a defining-process, undertaking its initial part.

Probably "initiate" would be es good a "declare", it's just to agree a convention, a possibility.

Best,

Andreas