A better way of managing backwards compatibility?

[Prudence via Digitalmars-d]

Dealing with changes to standardized interfacing such as api 
function names, namespaces, file names/module names, etc is 
usually impossible to do because it severs the code written 
before the change from the new compiler. Most people think this 
is the way to do it and there is no, better, alternative.

Well, *NOW* there is:

One could completely change D(could replace it with a Fortran 
version, if desired) yet still keep backwards compatibility!!!! 
And it would be relatively easy.

"How can this be possible", you exclaim with relative disdain!!

Well, there are two distinct but compatible ways:


1. Essentially keep track of the version the compiler that is 
currently being used to compile the project, somewhere. (or one 
might be able to infer this from the dates, as long as one has a 
date to version mapping, but this is not accurate)

As long as those binaries of the compiler(and source would be 
nice) are somewhere, the user can be informed to download the 
correct version and/or have the D compiler automatically do this 
for it.

Note though, the requirement for D is only that it can do the 
checking and possibly downloading of another compiler. In fact, 
it could have it such delegating facilities to compile Fortran by 
similar means or it could be the D3 compiler that downloads D1 
for some ancient source code.


2. Write a translation process that essentially "updates" the 
source code to work.

Suppose D **wanted** to change a keyword for some reason or 
another. The compiler first runs the code through the translation 
process which mostly is just a token replacer but it could be 
more advanced and modify function differences(such as a swapping 
of two parameters).

The good news, is that such a feature is easy to implement as it 
is just a mapping of the token stream to another. The hard part 
is getting everyone on a high enough level to put such changes in 
the translation process when they modify the compiler or library 
or whatever.

For example, if we wanted to change "for" with "pour" then the 
parser just as an additional step. Instead of something like: 
parse(token[i]); we would have: parse(translate(token[i])); Where 
translate is just a string to string map, and we could make 
translate more complex by dealing with 
context(parse(translate(token, i)).

Again, one would have to know the version in some way.

We can think of 1 and 2 as different ends of the granular 
spectrum. 1 will get the correct version used and use it. It has 
to work, if not, then it wouldn't have worked anyways(user/setup 
issue) since this is sort of just automating what a user can do. 
I believe there are already tools that sort of emulate 
this(allows you to switch between versions easily but they are 
dumb(no memory and no automation)). 2 generally deals with simple 
changes.


The good news is that all this can come from just knowing the 
version to compile the source with. This then gives the compiler 
designer the freedom not to worry about naming stuff perfectly. 
Documentation is not a problem, as the same translation and 
versioning can be automated in the same way using the same data.

e.g., go to the docs, if you are using an old version, select the 
version, your correct documentation shows up.


What these two processes, together, do, is essentially gives a 
discrete "history" of the compiler. It would be like an 
continuous incremental backup of every change to a compiler, but 
since most changes do not effect source code backwards 
compatibility, One doesn't need every single change.

It also allows one to migrate to new versions seamlessly.

Imagine going from D1 to D2, but it's just D anyways because the 
versions "don't matter" anymore.

1. The compiler will try to translate the D1 source to the D2 
source through a series of micro translations(for each version we 
would have a translate). If it fails at some point, it will 
report to the user the "errors in translation" which can be due 
to a syntax change that is known to break versioning. (e.g., 
change for(i=0;i<10;i++) to for i=0,9,1, which breaks code 
because of semantics... although with a more intelligent 
translator this specific case can easily be handled)

2. If step one fails, which depends on how many times it has to 
be called, the further way the versions we are going between the 
more likely step 1 will fail. In that case we revert the "exact" 
compiler needed by finding and using the correct compiler that 
the source code was designed with.


Of course! We would want this to be build in to the compiler from 
day one. But step 2 saves us with D!! Since almost every version 
has been saved, we can pretty much use step 2 the whole time.

What to this do for everyone when implemented properly? Simply 
keep the versions with the source code somehow(embed in source in 
a comment at the bottom of a file or in a configuration file 
somewhere), and keep the translation changes up to don't on 
compiler modification, and include this feature in the compiler, 
and then ***NO ONE*** will have to worry about versions again. 
(at worse, if they want to use the tools manually to translate 
the software to a working version then manually edit it to get it 
past a break(essentially replace step 1 with actually fingers on 
the keyboard... and if their smart, they could add those changes 
to the translation database for that version which the compiler 
could use(pull from the cloud))