On Apr 19, 2009, at 6:36 AM, Derick Eddington wrote:
[...]
What this demonstrates is (according to my understanding):
- PLT (mzscheme) makes a new instance of a library (T0 in this
example)
every time it processes an import of it, and then some. I understand
why eight of these instantiations happen, but I have no idea why the
other five happen.
I can't justify it either. Actually, on my machine, I get only 10
instantiations (using "plt-r6rs ++path . t.sps") and not 13! I bet
you'd get a different number of invocations in DrScheme due to the
check-syntax feature.
Why the
other five happened I have no idea, and because I have no idea, I'd be
even more discouraged from considering trying to utilize PLT's
multiple-instantiation semantics, even if I was okay with using
library
instantiation to accomplish visible side-effects (which I'm not
because
I think it's anti-functional and too unpredictable because it's too
complicated).
Which goes counter to the whole argument of the plt semantics which
is to tame side effects and make them predictable and manageable.
- Ypsilon and Larceny have single-instantiation semantics, and they
make
a single instance of a library whether or not an instance is actually
needed, and that's why in the example they display T0 once.
This is slightly incorrect. If the script imports T0 only for (meta
-1),
Larceny would not invoke it, while Ypsilon would. I think Ypsilon
invokes all imported libraries anyways regardless of anything, but I'm
not absolutely positive.
[...]
So, because of all this complication about time and number of
instantiation, which exists at least to some extent for every one of
these R6RS implementations, the only library instantiation side-
effects
I feel I can ever hope to have a chance of managing are those used for
initializing library-private data, the initialization of which has no
visible side-effects and is not dependent on the time or number of
instantiations.
If you can manage to do this, then your library would work on all
systems (modulo performance, compile times, etc.), which is good.
[There are other problems with multiple instantiations that were
discussed on c.l.s. such as managing global resources. Imagine that
T0 there contained a guardian to guard some resources. Now you have
13 of them at different library instance, 12 of which inaccessible
when the program finally runs and thus garbage along with all the
resources they're intended to protect.]
This is the usual rationale for adhering to functional
techniques -- side-effects just get too complicated too fast to use in
any but the most encapsulated and controlled ways. I imagine Ikarus's
only-when-needed single-instantiation semantics is based on this
reasoning.
I believe (sounding like a beauty pageant) that libraries should be
written so that they behave the same regardless of how they are
compiled (in batch or separately). This view has many consequences,
one of which is that libraries that modify other libraries simply
break down. The PLT answer is to only support separate compilation,
in essence shooting the patient to kill the disease. Yet I believe
there is a functional solution that does not involve side effects to
many problems (e.g., those in the "you want it when" paper which
started the whole thing); we (as programmers and implementors) just
have to think harder.
Yes, if every detail of the behavior was nailed down it
would be more predictable, but then implementations would be much more
restricted in what they can do to cater to different markets of users
and to what extent they can leverage their investment in past design
decisions.
Plus, it may be nailed down incorrectly, like what was going to
happen in R6RS had I not fought to unnail it. If it were nailed to
the PLT semantics, I probably would have voted against R6RS and
definitely not implemented it (so would others I guess).
[...]
The portable intersection of this library instantiation issue is the
no-visible-side-effects convention. I think that's all you should
write
about this issue in your series, so that you don't overwhelm the
readers. [...]
The majority of the libraries don't even require explicit
initialization: they only export some procedure definitions and
maybe some macros. Libraries in the wild are not supposed to print
stuff to the console since that limits their utility (e.g., you
cannot use them in a CGI script). So, I agree, focusing on the
usual libraries that don't involve side effects or macros would be
more suitable (or gentler) for the first article or two. Otherwise
it would feel just too overwhelming for people who haven't probably
thought it possible to perform computations (let along side effects)
at compile time. Just a thought.
Aziz,,,
