help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Avoiding 'reference to free variable' warningswhilesplittingelisp so


From: Drew Adams
Subject: RE: Avoiding 'reference to free variable' warningswhilesplittingelisp source files
Date: Sat, 23 Mar 2013 15:41:26 -0700

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]