defvar and (declaim (special
Immanuel Litzroth
difference between.
(defvar *root-window*)
and
(declaim (special *root-window*))
These forms appear at toplevel in the file (actually only the second
one does). If they are equivalent, why the second form instead of the
(in my view) more logical first one?
Thanks in advance
Immanuel
Barry Margolin
They're equivalent. DEFVAR proclaims the variable special, assigns an
initial value if one is specified and the variable doesn't already have a
value, and assigns a documentation string if one is provided. Since the
above DEFVAR doesn't specify an initial value or documentation string, all
it does is proclaim the variable to be special.
As to why the author chose not to use DEFVAR, I guess that's just a
stylistic choice they made.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Kent M Pitman
> In article <m2bth3b...@plateau.rug.ac.be>,
> Immanuel Litzroth <imma...@plateau.rug.ac.be> wrote:
> >I am currently reading garnet code and was wondering if there was any
> >difference between.
> >(defvar *root-window*)
> >and
> >(declaim (special *root-window*))
> >These forms appear at toplevel in the file (actually only the second
> >one does). If they are equivalent, why the second form instead of the
> >(in my view) more logical first one?
>
> They're equivalent. DEFVAR proclaims the variable special, assigns an
> initial value if one is specified and the variable doesn't already have a
> value, and assigns a documentation string if one is provided. Since the
> above DEFVAR doesn't specify an initial value or documentation string, all
> it does is proclaim the variable to be special.
>
> As to why the author chose not to use DEFVAR, I guess that's just a
> stylistic choice they made.
I concur with Barry's analysis but add that in some implementations,
DEFVAR does the additional implementation-dependent service of complaining
if you do it in more than one file. That is, you get a "being redefined
by file Y, originally defined in file X" warning for a DEFVAR. So one of
the style things that people usually use is to have a "primary definition"
that is a defvar and "redundant" definitions (whether for separate loading
or forward referencing or modular independence) using the declaim.
Vassil Nikolov
Kent M Pitman <pit...@world.std.com> wrote:
(...)
> in some implementations,
> DEFVAR does the additional implementation-dependent service of complaining
> if you do it in more than one file. That is, you get a "being redefined
> by file Y, originally defined in file X" warning for a DEFVAR.
Shouldn't this warning occur only if Y's DEFVAR has an init-form?
I don't know how good this analogy really is, but I am thinking
about the way C treats global variables. (If I recall the
terminology correctly, a _definition_ has an initialiser,
otherwise it is just a _declaration_; in the absence of any
initialisers all declarations collectively serve as the
definition.)
Of course, it is not hard to learn to recognise (DECLAIM (SPECIAL *FOO*))
as an idiom for (DEFVAR *FOO*) though I'd prefer the latter (shorter,
expresses intent more clearly).
Vassil Nikolov <vnik...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Kent M Pitman
> In article <sfwhfqp...@world.std.com>,
> Kent M Pitman <pit...@world.std.com> wrote:
> (...)
> > in some implementations,
> > DEFVAR does the additional implementation-dependent service of complaining
> > if you do it in more than one file. That is, you get a "being redefined
> > by file Y, originally defined in file X" warning for a DEFVAR.
> (...)
>
> Shouldn't this warning occur only if Y's DEFVAR has an init-form?
I can see why you'd think so, but I think the answer is no.
There are (as usual) multiple reasons for this:
* First, if you edit the source, you want to definitively know that
something is or is not globally initialized. If you find a definition
in which there is no init, you want to stop searching--not to say
"well, maybe there's another definition that does initialize it".
* Second, there is a theory (that I subscribe to) that says it's just
a bug if there is ever more than one DEFVAR because you didn't set
up the load order right. Patching it with extra "definitions" (or
"half-definitions") doesn't help--it just makes your system unmodular
so that if you later move the definition you may have redundant
definitions that are not needed, and if you ever remove the main
definitions, the other half-definitions are lingering time-bombs that are
cuasing your code to not warn you about a now-undefined variable.
* Third, it is at least in principle useful for a system to notice that
you have changed (defvar *foo* nil) to (defvar *foo*) and to want to
ask you in the interactive environment if perhaps *foo* should be made
unbound. Any hope of doing this would be shot to pieces if the system
had to instead say "oh, maybe he just moved the defvar with the init form
to another file and replaced it with a for-declaration-only defvar here".
And even if a programming environment didn't have this feature, people
often want to make such inferences so the problem is the same for people.
> I don't know how good this analogy really is, but I am thinking
> about the way C treats global variables. (If I recall the
> terminology correctly, a _definition_ has an initialiser,
> otherwise it is just a _declaration_; in the absence of any
> initialisers all declarations collectively serve as the
> definition.)
I think C .h files and the idea of multiple declarations are an abomination.
> Of course, it is not hard to learn to recognise (DECLAIM (SPECIAL *FOO*))
> as an idiom for (DEFVAR *FOO*) though I'd prefer the latter (shorter,
> expresses intent more clearly).
I prefer to think of the DECLAIM as an apology for not putting the
system files in the right order. Its real purpose is to be subprimitive
to implement the DEFVAR behavior, and I would never recommend anyone
use (DECLAIM (SPECIAL *FOO*)) just as a matter of style.
Erik Naggum
| I don't know how good this analogy really is, but I am thinking about the
| way C treats global variables. (If I recall the terminology correctly, a
| _definition_ has an initialiser, otherwise it is just a _declaration_; in
| the absence of any initialisers all declarations collectively serve as
| the definition.)
|
| as an idiom for (DEFVAR *FOO*) though I'd prefer the latter (shorter,
| expresses intent more clearly).
um, the former is a declaration and the latter is a definition, very much
like the C terminology. doesn't it stand out as such, too? DECLAIM and
DEFine-VARiable? it's more than "idiom" to me, and if I were to look for
definitions, I'd be happy to find a DEFVAR without binding the variable
to a particular value.
it looks like a mere load-order hack to me.
#:Erik
Erik Naggum
| I think C .h files and the idea of multiple declarations are an
| abomination.
C should get all the deserved heat it can get, but in this case, it's
less ugly than it appears to be. there can be only one declaration of
any object, and only one definition in the appropriate scope. multiple
instances of each is an error. however, you don't have to declare
something, because the definition will itself declare it if it was
undeclared, and the definition doesn't have to be found in the same
compilation unit, only the declaration if there are references. the old
K&R C definition was pretty relaxed about these things, but ANSI and ISO
cleaned up this mess.
all of this in C is to support separate compilation of files with a
completely ignorant compiler that produces object files that contain
nothing but the bare essentials to build "executables". no other
language is able to survive at this level of pandemic ignorance, and
various harsh measures are required to cope with the compiler/linker
relationship in C and consequently under Unix, such as many output files
from the compiler and the danger of loss of synchronization between these
files, so there's no doubt they have serious problems, but it isn't
because of multiple declarations as far as the compiler sees it.
well-written C also keeps declarations in header files and definitions in
source files, so there should actually be only one decleration of each
object, anyway.
#:Erik
Kent M Pitman
> * Kent M Pitman <pit...@world.std.com>
> | I think C .h files and the idea of multiple declarations are an
> | abomination.
>
> C should get all the deserved heat it can get, but in this case, it's
> less ugly than it appears to be.
I agree it's more complex than I made it out to be. I had started to
say something more and changed my mind, and I'd *thought* I had gone
back and removed this remark from my outgoing message. Rather than
defend my position on this, I'll just accept your remarks as
"appropriate" and leave it at that.
Vassil Nikolov
Erik Naggum <er...@naggum.no> wrote:
(...)
> if I were to look for
> definitions, I'd be happy to find a DEFVAR without binding the variable
> to a particular value.
Let me see if I understand this correctly. Do you mean that you would
recognise (DEFVAR *FOO*) as a (minimalist) definition (and not a
declaration), and you would not look any further?
(In the absence of comments that say something like `definition
elsewhere,' of course.)
Vassil Nikolov
I should learn to mention C analogies less often (say, no more than
once per two months).
Let's return to Lisp. The following question occurred to me:
What should the programmer do if they want to only compile the
files making up a program without loading them?
Even if the file containing the variable definition is compiled
first, if it isn't loaded, compilation of subsequent files
would not work correctly if they don't contain either init-form-less
DEFVAR's or special declamations. So, what is the best practice?
Place the DEFVAR in a separate file and load it anyway? Or use
declamations anyway?
Notes:
This question assumes that local special declarations are impractical.
Correct me if I am wrong in thinking that DEFVAR (unless wrapped up
in EVAL-WHEN) affects the compilation environment only for the
compilation of the file in which it occurs, not for subsequent
compilations of other files.
Erik Naggum
| Let me see if I understand this correctly. Do you mean that you would
| recognise (DEFVAR *FOO*) as a (minimalist) definition (and not a
| declaration), and you would not look any further?
yes.
| (In the absence of comments that say something like `definition
| elsewhere,' of course.)
such would imply to me that the author didn't know what he was doing.
incidentally, I also think (declaim (special ...)) is a sign of someone
who has had to hack something up because whatever should have worked,
didn't.
#:Erik
Erik Naggum
| What should the programmer do if they want to only compile the
| files making up a program without loading them?
why should the programmer want to do that?
#:Erik
Kent M Pitman
> What should the programmer do if they want to only compile the
> files making up a program without loading them?
> Even if the file containing the variable definition is compiled
> first, if it isn't loaded, compilation of subsequent files
> would not work correctly if they don't contain either init-form-less
> DEFVAR's or special declamations.
You didn't say why you want to do it, but I recommend just doing the
compilation in a clean environment where loading is ok. It seems like
a contrived problem absent some details.
However, I will note that I think it's a bug that DECLAIM is scoped to
files. I wanted it scoped to WITH-COMPILATION-UNIT but people were
apprehensive at the time we introduced WITH-COMPILATION-UNIT that
somehow this would cause a problem. There was, at the time, no
"current practice" for WITH-COMPILATION-UNIT relating its effect to
DEFVAR, so people wanted to move cautiously. The thought was that
maybe an implementation would use the extra &KEY args to
WITH-COMPILATION-UNIT to provide additional functionality like this
"optionally". (It doesn't surprise me that no implementation has.
It should be the default--not something you have to request.)
> So, what is the best practice?
> Place the DEFVAR in a separate file and load it anyway? Or use
> declamations anyway?
Mostly I just go ahead and separate out the DEFVAR's into another file
and just load it anwyay, but I do observe the possibility of writing
(defvar *delayed-inits* '())
(defmacro defvar-delayed (var initform)
`(progn (defvar ,var)
(push #'(lambda () (setq ,var ,initform)) *delayed-inits*)))
(defun run-delayed-inits () (mapcar #'funcall *delayed-inits*))
so that your inits can get set up in the same place but the call to
(run-delayed-inits) can go in another file.
You could also write a function that scanned definition files for
defvar's and produced a consistent set of proclaims so that you could
preload the proclaims.
But all in all, I'd just load the other forms.
As a rule, the problem is way more complicated than just defvars
and defmacros but extends to any setup that the user might have done,
which could include (for example) a SETF of GET somewhere in an
EVAL-WHEN. To be 100% right, you must load all preceding files;
there is no substitute. If you're willing to be only partly right
or willing to use special discipline in coding, then you can do less,
and how much less you can do depends on the discipline you're using
or the amount of wrongness you're willing to tolerate.
> Correct me if I am wrong in thinking that DEFVAR (unless wrapped up
> in EVAL-WHEN) affects the compilation environment only for the
> compilation of the file in which it occurs, not for subsequent
> compilations of other files.
Same file only, yes. Bleah.
Barry Margolin
If autoloading is involved, and the author didn't move the variable
definitions into a separate file that should be loaded unconditionally
(perhaps this is included in "putting the system files in the right
order"), the DECLAIM is a necessary evil.
Kent M Pitman
> In article <sfwemls...@world.std.com>,
> Kent M Pitman <pit...@world.std.com> wrote:
> >I prefer to think of the DECLAIM as an apology for not putting the
> >system files in the right order. Its real purpose is to be subprimitive
> >to implement the DEFVAR behavior, and I would never recommend anyone
> >use (DECLAIM (SPECIAL *FOO*)) just as a matter of style.
>
> If autoloading is involved, and the author didn't move the variable
> definitions into a separate file that should be loaded unconditionally
> (perhaps this is included in "putting the system files in the right
> order"), the DECLAIM is a necessary evil.
I should say I don't oppose the presence of (DECLAIM (SPECIAL ...))
in the language. It is necessary subprimitively, and I do consider
debate on this matter to be still "in order". I take a strong position
on this partly because I want to elicit remarks about when the strong
position requires accomodation, and I'm sensitive to the need for
"necessary evils" in general, not in just this situation. I was mostly
beginning from the point of view of countering the claim that
(DECLAIM (SPECIAL *FOO*))
and
(DEFVAR *FOO*)
were "interchangeable". I don't think they are. I think the former is
subprimitive and for use in places where we goofed and the latter didn't
turn out to be enough. The former is also useful in implementing the latter.
I'm not sure I totally understood your autoload case. Are you saying
you need to have done (DECLAIM (SPECIAL *FOO*)) pre-autoload because if
the DEFVAR is in the file, code may still have had to be compiled pre-autoload
which refers to the special even before the autoload occurs? Or are you saying
something more elaborate? In a sense, if what you're saying is just that
autoloads have to behave as if loaded and therefore multiple declarations are
required to achieve this implementationally, I agree.
Also, I guess it's worth noting that PROCLAIM, not DECLAIM, is what's needed
in that case since we're not scoping to a file.
Barry Margolin
My .emacs has lots of (setq <variable> <value>) expressions for variables
that are defined in files that I autoload. The autoloaded files won't be
loaded until I actually try to use one of those facilities. I don't need
declarations, because the Emacs byte compiler doesn't warn about these
expressions, not to mention that SPECIAL declarations are meaningless in
Emacs Lisp, since it's dynamically scoped. But if Emacs required
pre-declaration of these variables, I would use DECLAIM rather than DEFVAR,
to avoid the "multiple DEFVAR of same variable" issue.
Erik Naggum
| My .emacs has lots of (setq <variable> <value>) expressions for variables
| that are defined in files that I autoload. The autoloaded files won't be
| loaded until I actually try to use one of those facilities. I don't need
| declarations, because the Emacs byte compiler doesn't warn about these
| expressions, not to mention that SPECIAL declarations are meaningless in
| Emacs Lisp, since it's dynamically scoped. But if Emacs required
| pre-declaration of these variables, I would use DECLAIM rather than
| DEFVAR, to avoid the "multiple DEFVAR of same variable" issue.
what good would a declaration do, though? SETQ at top-level would write
to the value slot of the symbol, and it doesn't matter much whether the
symbol is declared special or not at this time. the first DEFVAR to come
around would declare it special, but at that time, BOUNDP would be true
of that symbol, so DEFVAR wouldn't touch the value.
#:Erik
Tim Bradshaw
> My .emacs has lots of (setq <variable> <value>) expressions for variables
> that are defined in files that I autoload. The autoloaded files won't be
> loaded until I actually try to use one of those facilities. I don't need
> declarations, because the Emacs byte compiler doesn't warn about these
> expressions, not to mention that SPECIAL declarations are meaningless in
> Emacs Lisp, since it's dynamically scoped. But if Emacs required
> pre-declaration of these variables, I would use DECLAIM rather than DEFVAR,
> to avoid the "multiple DEFVAR of same variable" issue.
>
The emacs byte compiler *does* warn about these, at least in XEmacs it
does. It may be that there is some option to supress those warnings
which other emacs branches have turned on, but as far as I know the
new byte compiler has always warned -- I can't remember what the old
one did.
I (bizarrely?) use defconst for this because it avoids load-order
dependencies -- if you decide to dump a new emacs with some package
preloaded then your defvars don't set the value any more, while
defconst does. I changed from lots of setqs because I needed to get
the compiler to shut up a bit so I could see the genuine lossage.
--tim
Barry Margolin
>* Barry Margolin <bar...@bbnplanet.com>
>| My .emacs has lots of (setq <variable> <value>) expressions for variables
>| that are defined in files that I autoload. The autoloaded files won't be
>| loaded until I actually try to use one of those facilities. I don't need
>| declarations, because the Emacs byte compiler doesn't warn about these
>| expressions, not to mention that SPECIAL declarations are meaningless in
>| Emacs Lisp, since it's dynamically scoped. But if Emacs required
>| pre-declaration of these variables, I would use DECLAIM rather than
>| DEFVAR, to avoid the "multiple DEFVAR of same variable" issue.
>
Prevent a compiler warning about a variable being implicitly declared
special.
Erik Naggum
| Prevent a compiler warning about a variable being implicitly declared
| special.
since you were talking about simple customizations in something like
.emacs and such files are rarely compiled, I ignored compiler issues.
but since I'm already picking nits, now, a compiler should perhaps have a
right to inform the programmer that it _assumes_ something is special,
but the last time we visited this topic of whether SETQ at top-level were
meaningful, the conclusion I remember was that CMUCL was in error for
declaring a symbol special just because it was set at a top-level. so I
think the right solution to such compiler warnings would be to fix the
compiler.
#:Erik
--
environmentalists are much too concerned with planet earth. their geocentric
attitude prevents them from seeing the greater picture -- lots of planets are
much worse off than earth is.
Barry Margolin
>* Barry Margolin <bar...@bbnplanet.com>
>| Prevent a compiler warning about a variable being implicitly declared
>| special.
>
> since you were talking about simple customizations in something like
> .emacs and such files are rarely compiled, I ignored compiler issues.
I was making a general point, and using .emacs as an example of a place
where it's common to refer to variables that are defined in files that have
not yet been loaded, because of autoloading.
> but since I'm already picking nits, now, a compiler should perhaps have a
> right to inform the programmer that it _assumes_ something is special,
> but the last time we visited this topic of whether SETQ at top-level were
> meaningful, the conclusion I remember was that CMUCL was in error for
> declaring a symbol special just because it was set at a top-level. so I
> think the right solution to such compiler warnings would be to fix the
> compiler.
CMUCL's behavior is a different issue. It didn't just assume the variable
was special, but declared it special pervasively. I.e. it interpreted
(setq foo ...)
as
(declaim (special foo))
(setq foo ...)
whereas most others treat it as
(locally (declare (special foo))
(setq foo ...))
Kent M Pitman
> CMUCL's behavior is a different issue. It didn't just assume the variable
> was special, but declared it special pervasively. I.e. it interpreted
> (setq foo ...)
> as
> (declaim (special foo))
> (setq foo ...)
> whereas most others treat it as
> (locally (declare (special foo))
> (setq foo ...))
Though implementations do tend to agree that a free reference is to a
special (for want of something better to do, I suppose), I doubt you
can find anything in the spec that requires free variables to have any
meaning at all in that context.
This came up particularly in the discussion of lexicality because when
we found that there was not agreement that if there were global lexicals,
they would necessarily share the same global value cell as global specials,
a consequence was that it wasn't clear that if there were global lexicals,
saying (setq x 3) would necessarily access a special. (There are many
possibilities even in that scenario: no global lexicals, in which case
probably the global special cell would be used; global lexicals and specials
possible, sharing a value cell, in which case it didn't matter whether you
interpreted the reference as special or lexical; and global lexicals and
specials possible with distinct value cells, in which case the reference
is either lexical or special or perhaps an error absent some declaration
clarifying the intent.) My recollection is that CL tried to steer clear
of this as an area for future growth.
Vassil Nikolov
Erik Naggum <er...@naggum.no> wrote:
> * Vassil Nikolov <vnik...@poboxes.com>
> | What should the programmer do if they want to only compile the
> | files making up a program without loading them?
>
(Sorry for being slow in responding, that was not a purposeful delay.)
I asked that as a general question, I don't have a specific
case at hand. Some reasons I can think of are (in no
particular order):
* loading each successive program file would eventually take
up too much memory, leaving too little for compiling the
rest of the program;
* load-time computations would make the compilation process
unacceptably slow;
* some of the data needed for load-time computations are not
available at compile time^1;
* the program is being only compiled to an intermediate
language such as C (with the compiler output due to be
combined with other components that do not come from Lisp,
instead of being compiled to object code to become loadable
into the Lisp image).
__________
^1 one particular case of this may occur when the program
being compiled is intended to be run in another environment
(e.g. another machine; this is not necessarily
cross-compilation---could be another instance of the same
platform), and loading it requires things available in that
environment but not in the environment where it is compiled
None of these would occur very often, of course, so if you
say that none of these is a good reason, I am not going to
argue with that. (But I would be interested in any comments.)
As Kent Pitman pointed out, the real solution is to have a
good WITH-COMPILATION-UNIT. I wonder what effect that might
have on the usage of DEFSYSTEM's compile-then-load operation.
--
Vassil Nikolov
>
> > What should the programmer do if they want to only compile the
> > files making up a program without loading them?
> > first, if it isn't loaded, compilation of subsequent files
> > would not work correctly if they don't contain either init-form-less
> > DEFVAR's or special declamations.
>
> You didn't say why you want to do it,
Now I have given some answers in my response to Erik Naggum's post.
> but I recommend just doing the
> compilation in a clean environment where loading is ok. It seems like
> a contrived problem absent some details.
Yes, it is, at least to some extent, I guess.
> However, I will note that I think it's a bug that DECLAIM is scoped to
> files. I wanted it scoped to WITH-COMPILATION-UNIT
(...)
I would very much like to have WITH-COMPILATION-UNIT fully functional,
for example with respect to maintaining the compilation environment
for its dynamic extent. If it were so, I don't think I would have
asked my question above.
(...)
> so that your inits can get set up in the same place but the call to
> (run-delayed-inits) can go in another file.
Yes, thought I don't very much like the idea of separating initialisation
into more than one piece when there isn't an essential reason for that.
(`Essential reason' would be for example one that makes it impossible
to finish initialisation at load time, mandating some initialisation
at run-time.)
(...)
> or willing to use special discipline in coding
(...)
I am willing to do that provided it is necessary, i.e. the program
goes out of control otherwise.
> > Correct me if I am wrong in thinking that DEFVAR (unless wrapped up
> > in EVAL-WHEN) affects the compilation environment only for the
> > compilation of the file in which it occurs, not for subsequent
> > compilations of other files.
>
> Same file only, yes. Bleah.
This is an expression of disapproval, isn't it? (Sorry for asking
a probably stupid question, but being a non-native speaker I can't
be quite sure of the meaning of such words relying on my own
sub-symbolic language processing only. There are some papers by
Robert French where he argues that such words could be used in
a Turing test to identify the machine; in particular, he suggests
questions like, `is flugbloggs a good brand name for a cereal.'
I know from the paper it isn't, but I have no feeling for it as
I would have for the analogous case in my native language.)
Erik Naggum
| I asked that as a general question, I don't have a specific case at hand.
then my specific question is how you came to ask that general question.
this is not to quibble -- I need to know how you come upon questions the
answer for which has no expectation of value to you.
I realize that underneath your approach is a desire to let the answers to
the question define the meaning of the question and that it would be an
interesting exercise to find the most valuable answer in this regard, and
that I thwart your approach by asking you to make the question specific
before it has any meaning, i.e., answers, _but_ I would still very much
like to know what thought processes generate the questions and what they
are based on. I think I could fill the underlying desire to learn in
much more efficient ways, or learn from same in much more efficient ways,
if I knew what makes up a good question of the kind you make.
incidentally, I think computing the optimum load-order for a set of both
functions and variables and declarations and macros and all this good
stuff is a very challenging task, which effectively asks of a fully
loaded system "how did you get here, and what's the best way to do it
over again". this question could also be asked of a running Unix system
to make it dump configuration files in such a way that it would return to
the same state after a boot sequence, so it is a question that pertains
to any system that accepts changes to itself after it has started running.
Vassil Nikolov
Erik Naggum <er...@naggum.no> wrote:
> * Vassil Nikolov <vnik...@poboxes.com>
> | I asked that as a general question, I don't have a specific case at hand.
>
> then my specific question is how you came to ask that general question.
> this is not to quibble -- I need to know how you come upon questions the
> answer for which has no expectation of value to you.
>
> I realize that underneath your approach is a desire to let the answers to
> the question define the meaning of the question and that it would be an
> interesting exercise to find the most valuable answer in this regard, and
> that I thwart your approach by asking you to make the question specific
> before it has any meaning, i.e., answers, _but_ I would still very much
> like to know what thought processes generate the questions and what they
> are based on. I think I could fill the underlying desire to learn in
> much more efficient ways, or learn from same in much more efficient ways,
> if I knew what makes up a good question of the kind you make.
You ask a good question, and with good reason, but it is a rather
difficult one. I don't see it as quibbling or thwarting anything,
it is just that the attempt to answer I am about to make may or may
not produce a satisfactory result.
My question was basically, how do I organise a Lisp program
(consisting of more than one file) so that I don't have to
load the files in order to compile them. In particular, how
do I arrange definitions and declarations of global variables.
In no particular order:
For one, I discovered there was incompleteness in my knowledge, and
some misbeliefs, so I wanted to correct that. In particular, I saw
that my thinking about (DEFVAR FOO) (no initial values) as a
declaration (and not a definition) was perhaps not very adequate.
(I say `perhaps' because I have not thought this over in full.)
For two, it's not that I object for compiling and loading to go
together, it is just that when I think about it or do it, I feel
that sometimes this is more than I want. Maybe this is not
typical, but when I have finished (the current round of) developing
a program, I just want to compile it before ending the Lisp session,
and having to load any file appears like having to do an extra
operation, and I dislike doing redundant things. To put it in
another way, doing COMPILE-FILE and then LOAD looks somewhat like
putting EVAL-WHEN with all three situations around each form in
the file, and I don't find that elegant.
I feel there is more, but it refuses to emerge.
So I asked the question mostly out of a desire to learn, and also
a desire to equip myself with better practices in doing Lisp.
And yes, I want to develop an approach to organising programs that
puts them in order with respect to definitions and loading and that
makes it less likely that inconsistence may be introduced if some
change is made to the program.
> incidentally, I think computing the optimum load-order for a set of both
> functions and variables and declarations and macros and all this good
> stuff is a very challenging task, which effectively asks of a fully
> loaded system "how did you get here, and what's the best way to do it
> over again". this question could also be asked of a running Unix system
Also `what would happen if one did it again, and which are the
non-idempotent aspects of doing it again' (if I may use `idempotent'
here in this way).
> to make it dump configuration files in such a way that it would return to
> the same state after a boot sequence, so it is a question that pertains
> to any system that accepts changes to itself after it has started running.
By the way, on my first encounter with a running UNIX, about which
I knew very little at the time, I assumed that shutting it down and
then bringing it up would restore the state. I don't really know
why I assumed that---it just sort of looked that way^1---and of course
I quickly found out that I had overestimated UNIX capabilities. And
dumping configuration files and not core images is of course the right
way, it looks to me analogous to vector vs. raster representation of
images.
__________
^1 that was SunOS 4.0 about 10 years or so ago
>
> #:Erik
> --
> environmentalists are much too concerned with planet earth. their geocentric
> attitude prevents them from seeing the greater picture -- lots of planets are
> much worse off than earth is.
This makes me wonder if there are lots of planets that are better off...
Kent M Pitman
> I just want to compile it before ending the Lisp session,
> and having to load any file appears like having to do an extra
> operation, and I dislike doing redundant things.
Of course, if it were redundant, you wouldn't have to do it. ;-)