[erlang-questions] How to get the line number of current executable code?

[Richard A. O'Keefe]

On 21 Aug 2008, at 10:16 pm, Andras Georgy Bekes wrote:

>>  - 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  
'funs'.

>
> 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
> difficult.

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  
eventually
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
	was.

	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...)

>
> 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.