I don't know where this all came from or who said what, but I would like
to elaborate on this library instantiation business
Extrapolate this example to an import set (including all its
transitive
imports) with multiple libraries utilized only at (> phase 0) --
do you
really want those libraries instantiated and consuming memory at
run-time even though that's totally unnecessary?
Yes, all the languages I know work in this way, and nobody
complains about the waste of memory.
First off, you obviously don't know Java. :-) Java classes do
not work this way, and people there do worry about wasted
memory and class initialization issues. The Java
initialization semantics are described in:
http://java.sun.com/docs/books/jls/third_edition/html/
execution.html#12.4
The moral of the story is that depending on where you come
from, you would have some expectations about "when" things
happen, and everybody else in the world might as well be a
martian.
So, let's admit that we're all from different planets and
let's put all of our semantics on the table. The
possibilities so far are:
1. Instantiate all imported libraries (ypsilon)
2. Instantiate libraries that define variables that are used
before code that uses them is evaluated (implicit phasing)
3. Instantiate libraries that define variables when a variable
is referenced (Java)
4. Instantiate libraries whose effective phase (after adding
and subtracting meta levels) is 0 (explicit phasing).
Of these, one can do further "optimizations", for example, if
a library exports a variable bound to a simple value (for some
definition of simple), then only the simple variable value is
computed without instantiating the whole library. Or one can
defer the decision for instantiation after inter-library
inlining, so that even procedures that are used in other
libraries may not cause instantiation. And so on ...
Now let's (for a change) take a real library, not one
contrived library that's written to show the differences, but
one that's written in an honest-to-god way. Take SRFI-1 as an
example.
I claim that SRFI-1 is going to work correctly under *ALL* of
these instantiation semantics and more! If anybody wants to
challenge this claim, speak up.
I would also say that if there is any collection of Scheme
code that's going to run on systems 100 years from now, SRFI-1
is going to be in it.
Note that Olin's code is portable not because the whole galaxy
agreed on one particular instantiation semantics; that's
absurd. Portability of Olin's code is a virtue of the code
itself: it does not depend on irrelevant and obscure details
like the ones we've been beating to death.
I would go as far as to say that code that depends on such
silly implementation details suck and this rule is transitive:
if you write sucky code, then you suck too. (courtesy of Steve
Yegge) And if you're going to advocate one silly detail over
the other, and you encourage people to write fragile code that
depends on the semantics-of-the-day, then you suck on a
negative meta level. (this sentence is for a generic "you",
I don't mean to offend anyone, and if you feel offended, then
you suck!)
Aziz,,,
