From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: Avoiding 'reference to free variable' warningswhilesplittingelisp source files Date: Sat, 23 Mar 2013 15:41:26 -0700 Message-ID: References: <20130323090800.172d8df4@gauss><34FC3C03F8024543AA455B46C30A3AE7@us.oracle.com> 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 1364078512 10832 80.91.229.3 (23 Mar 2013 22:41:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Mar 2013 22:41:52 +0000 (UTC) To: "'Stefan Monnier'" , Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Mar 23 23:42:15 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UJX8h-0000ol-9f for geh-help-gnu-emacs@m.gmane.org; Sat, 23 Mar 2013 23:42:15 +0100 Original-Received: from localhost ([::1]:36495 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJX8J-0006j7-Hu for geh-help-gnu-emacs@m.gmane.org; Sat, 23 Mar 2013 18:41:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJX87-0006iy-Ic for help-gnu-emacs@gnu.org; Sat, 23 Mar 2013 18:41:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJX86-0005PV-4y for help-gnu-emacs@gnu.org; Sat, 23 Mar 2013 18:41:39 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:36694) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJX85-0005PB-Tt for help-gnu-emacs@gnu.org; Sat, 23 Mar 2013 18:41:38 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2NMfZJ2005732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 23 Mar 2013 22:41:36 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2NMfZUJ021230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Mar 2013 22:41:35 GMT Original-Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2NMfYYu019128; Sat, 23 Mar 2013 17:41:34 -0500 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 23 Mar 2013 15:41:34 -0700 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: Thread-Index: Ac4oCkJzKbabZZmIQBSdeVT/qdUl1QAAvDdg X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:89701 Archived-At: > 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.]