Post by unknown Post by unknown
- the meta-data for a module records which exported functions are
pure and which are not
- when the compiler notes a pure function calling a function
from another module, it records a dependency on that function
being exported as pure
- when a module is loaded, the run time system checks that
every function it tries to import as pure from some other
module IS pure if that module is already loaded,
every module that depends on this one exporting some
function(s) as pure is satisfied.
If either check fails, the module is not loaded.
This is completely against current Erlang practice.
(a) That's a very misleading way to put it.
It would only be "against" if it in some way opposed or prevented
the kinds of things people are doing.
Erlang *happens* not to check very much, but this is hardly a
core design principle.
(b) IT DOESN'T MATTER!
For heaven's sake, I was answering a question about an idea I had
more than ten years ago, which was abandoned when Erlang got
Post by unknown
Currently if a module A uses module B, noone checks if B contains the
used functions or not. Neither at compile time, nor at module load
time. I think because the check would make module upgrades way more
First off, you can't do it at compile time because you do not know
*which* module called B, or which version of that module, A will
be loaded with. That's why it needs to be a load time conversion.
Second, haven't we all heard enough about "Version Skew" and "DLL Hell"
over the last N years to convince us that making it as easy as possible
for people to shoot themselves in the foot is not always a Good Thing?
If you have two loaded modules, A and B, and A uses something that B
provides, and you replace B with a B' that does not provide that any
more, what you have done is NOT an upgrade. What you have done is to
convert a working system into a non-working system. If you have a
new A' that doesn't need that service from B', then either you need
to change A to A' first, or you need to replace both modules *together*.
Just at the moment I am vey hot under the collar about "upgrades".
Here's my story:
I have a Macintosh on my desk.
I have to teach 5 introductory programming lectures to
first year surveyors. The surveying department insisted
on Visual Basic as the programming language. Since their
students will mostly be making minor additions to Excel
spreadsheets, this almost makes sense.
Fortunately, Excel is part of Microsoft Office for the Mac,
and last year I was able to develop examples using VBA in
Excel on my Mac.
This year the system administrators installed Microsoft
Office 2008 for Macintosh on my machine.
It wasn't until I tried revising my materials for SURV112
that I discovered that Office 2008 does not include VBA
any more. Gone. Vanished. All Office 2008 can do with
VBA macros is offer to delete them. We're supposed to
use AppleScript instead.
I've taken the trouble to learn AppleScript, and it is
certainly integrated with MacOS in a way that VBA never
None-the-less, I am ***HOPPING MAD*** that nobody told
me when the "upgrade" was done "Oh, by the way, this is
going to remove a feature you need for your work; do
you really want it?"
If my configuration is inconsistent, I d--n well *WANT* to be
told about it before the damage is done.
I am not arguing against hot loading.
What I don't like is *silently* moving to an inconsistent state
or a state where functionality I rely on is missing.
(I've also lost the ability to print slides, because Acrobat 8
has this weird bug where slide pages after the first are mirror-
imaged, and the sysadmins were terrified at the thought of the
trouble they've have trying to replace it with an older version.
Hopefully Acrobat 9, which they've now installed, fixes this...)
Post by unknown
Now think about a module A using B's BF and B using A's AF. When both
functions are removed, there is no legal upgrade order.
Yes there is. It's A+B *together.
I am not saying that this is supported *now*,
but it could be, and it should be.
And for the "block compilation" that people keep mentioning,
it will *have* to be, for this very reason.
You see, when you say "there is no legal upgrade order",
what that *really* means is that "if you replace modules one
at a time, there can be unavoidable windows when the system
is in an inconsistent state, does not know that, and tries
to continue operations anyway." Does that sound like a good idea?
Anyrate, to repeat: this was *NOT* a current proposal,
otherwise it would have been an EEP, not an off-hand remark
in another thread, so it was pointless to criticise it.