Language change and code breaks

[Tim Churches]

Peter Hansen wrote:
> 
> Guido van Rossum wrote:

-----8<----snip---------
[ discussion of ways of preventing changes to Python breaking existing
code ]
-----8<----snip---------

I'm just about to head off to a 1 week statistics workshop in which the
Stata package (see http://www.stata.org) will be used for teaching, so I
thought I had better crack open the Stata manual...

Although Stata is a proprietary, closed source package, Stata Corp. has
actively encouraged end users to write their own extensions to Stata
using the Stata scripting language (about which the less said the
better...), so there is a large body of work written using various
versions of Stata from 1.0 to 7.0 (in 0.2 or 0.5 version increments, it
seems). Stata Corp actively distributes these extensions via a built-in
download facility or via CD-ROMs.

The first thing which caught my eye in the manual was the "version"
statement. This statement modifies the behaviour of Stata to mimic the
specified version, thus allowing old scripts to run unchanged under new
versions. Not only that, it does so at run-time, allowing old and new
code to be combined, such as, in a single script:

version 2.1 /* emulate Stata 2.1 */
...assorted old Stata code....
version 6.5 /* emulate Stata 6.5 */
...newer code...
version 7.0 /* revert to current version behaviour */
...code to take advantage of latest changes to syntax...

This behaviour modification seems to extend not just to the Stata
kernel, in which the core syntax is defined, but also to Stata
libraries, so that if you specify "Version 2.1" you even get the old
style random number generator instead of the better one introduced in a
later version. 

This seems like both an excellent solution and a very neat trick. Having
never looked into the bowels of the Python bytecode compiler or VM, I
have no idea whether such a thing would be feasible, but it is an
attractive idea, at least superficially. It appears to have worked well
for Stata.

Tim C
Sydney, Australia