ideas for the IDE

[Erik Zuurbier]

Say we want to overhaul some standard module, for instance to let it use
new features such as constructor classes. If we simply throw away the old
module and
put in the new one, major shit happens when we try to compile an old program.
Old functions that the program relied on don't exist anymore, or they have
new types, causing typing problems. Or worse still, some functions may compile,
but have a different meaning, fixity or run-time behaviour. The following
ideas are meant to reduce the pain of weeding through endless lists of
error messages and run time problems.

The idea is this. Instead of providing a new module, the programmer creates
a combined version of the module that contains:
* Everything from the old version that changed or dissappeared in the new
version. The programmer labels all these components as obsolete by some
pragma that the compiler understands.
* Everything from the new version.

When this combined module is compiled, the compiler could find two
different definitions of the same function name, one being obsolete. One
function of the 'obsolete' pragma's to suppress the error message about
this. It would be nice though if the compiler would complain about obsolete
and new items calling eachother.

When an old program, which uses the module, is compiled and for a certain
function it turns out that there (also) exists an 'obsolete' definition,
the following possibilities exist:

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

*2 There is a substitute for the obsolete function in the new version. The
substitute's name should be explicitly added to the obsolete function, also
in some kind of pragma. The following subcases now exist.

*2a The module programmer has decided that with an easy source-to-source
transformation the program would be ready for the new module. The module
programmer specifies this source-to-source transformation in the combined
module (in yet another kind of pragma). When the program is compiled, on
request the IDE could attempt the source-to-source tranformation, IF it
would not introduce any name clashes. If it would, the IDE could generate
an error message to that effect.

2b The module programmer did not specify a source-to-source transformation.
Another pragma in the module source code could contain a detailed
explanation by the module programmer, of what should be done to solve the
problem. The compiler displays this explanation as a warning/error message.


Say that the new and the old function names are the same, or otherwise the
new name also appears as an old name. After solving a problem and
recompiling, the above scheme would then again identify case 2.

That can be avoided if the source code of the program that uses the module
would maintain an extra bit of information for each call to such a
function. That bit would initially be zero. The IDE would set this bit to
one as soon as the programmer confirms that the call has been converted
according to the requirements of the new module. Needless to say that the
compiler should inspect this bit and suppress the relevant error message if
the bit is one.

Comments?

Erik Zuurbier