ideas for the IDE; 'obsolete pragmas'

[Marco Pil]

Dear Erik,

I read your mail about 'obsolete pragmas' with great interest. It seems to
provide
a solution for a problem I was just dealing with (see below for a description).

There were a few things I didn't understand:
 > *1 There is no substitute for the obsolete function in the new version:
 > This should be indicated explicitly for the obsolete function in the
 > combined module: a new function with the same name may not be a substitute.
 > The compiler can then generate a warning message, informing the programmer
 > that the function is going to disappear in the next version of the module.
 > This is better than what we now have: the message "function not defined".

Why is "This function is going to disappear" a better message than  "function
not defined"? If the function has become obsolete, any reference to this
function
must be gone, so no message "function not defined" will be generated.

And what about this source-to-source transformation? If the old version of
the function
has been conserved, can this not simply be used whenever it is needed ?!

Regards,

Marco Pil


============================================================================

A description of the above mentioned problem:
---------------------------------------------

With the implementation of dynamics I have encountered a similar problem.
[A dynamic is a pair of an object and its type, that can be written to
file, and thus
 enables a form persistence in a strongly typed file system.]

The graphs representing the objects that are written to file have to be
encoded.
A function is encoded by a pointer to its code, i.e. a pointer to the object
file of the module in which the function has been defined.

A problem arises when the defining module has been recompiled. The code
that represents
the function may be altered completely, and might be no longer suitable for
its older
task. This makes its necessary to somehow keep the older version of the module.

For each function in the module there are three possibilities:
1. The function has not been changed.
2. A bug in the function has been fixed, but otherwise the function remains
the same.
     Then it would be nice if pointers from dynamics to this function could
point to this
     latest version.
3. The function really has been changed.
     Then it is necessay that pointers from old dynamics keep pointing to
the old version
     of the function.

The compiler should be able to decide which case is applicable. We do not
distinguish
between cases 1 and 2, but use the following rule of thumb: If the type of
the function
has not been changed, the new version can be used. This enables the compiler to
decide automatically whether pointers from old dynamics should point to the
latest
version or not.


Problem: It is possible that two functions in a dynamic, say f and g, point
to different
versions of the same module, say f points to the second version of module
m, and
g points still to the first version of module m, since in the second
version the function
g had been assigned a different type.
This is undesirable since f and g may be written with an implicit
assumption (say to start
counting from zero) in the first version, and a different assumption in the
second one
(start counting from one).
If g is represented by old code using the old assumption, and f by new code
using the
new assumtion, an inconsistent system results.


My first solution was in only updating the dynamics to point to the latest
version if
none of the functions had been changed, i.e., no functions had been left
out, and no
types had been changed (other than being more general).

But then a bug-fix would only affect the older dynamics, if the module
change did meet
with this compatibility requirement. Once a function has been left out or a
type has
been changed, later bug fixes would have no effect on the old dynamics.


A pragma with which the programmer can annotate the functions which have become
obsolete might provide a solution. All old functions may stick around in a
dormant
state, only to be awaken once in a while by pointers in dynamics from the past.