Lambda the Ultimate

I'm wondering why this isn't commonly done. It seems to me that during the evolution of most languages, you reach a point at which you realize that you would like to improve the syntax of the language, and it would be best served by changing the existing language incompatibly, but, as the language designer, you're afraid of the errors that you will introduce into the large source code base which already exists.

If modules were explicitly tagged with a language version, then you could ship a compiler, which was really a compiler collection, that could compile any number of modules written in any number of incompatible language versions. It doesn't seem like this would introduce any extra maintenance burden either.

What is it that I'm missing?

Second, this idea sounds reasonable to me. I think Python has an interesting way of handling language versioning, with its `future import' mechanism. XML also has explicit versioning.

It is easier to try and introduce language features that are backward compatible, and clearly state when recompilation is required, to what scope and what are the changes and difficulties programmers should expect.

If the changes between versions are only syntactic sugar, and whose semantics can be expressed by translation to a core language which does not change across versions, then it would not be so hard to assure interoperability in a way which most programmers can understand.

Python's development team has gone a bit further than that. As well as future imports there's also the PendingDeprecationWarning and FutureWarning classes to indicate that you're using features that are likely to change in the future.

I also seem to remember that there was some discussion in one of the earlier Perl apocalypses about handling interoperability between Perl5 and Perl6. Here's the link: http://www.perl.com/pub/a/2001/04/02/wall.html. The interesting thing is that Wall is particularly worried about the situation where you're running Perl5 code in Perl6--do you use Perl6 semantics, Perl5 semantics or some special compatibility mode that's going to minimize unpleasant surprises?

Scoping and keywords are clearly not a problem because they are syntactic issues, but you do raise two good points.

First, I was thinking (as I always do :) of a functional language, which always have a compositional denotational semantics: the denotation of a program depends only on the denotations of its subprograms, and not on the way they are expressed, or on programs which are not mentioned in the source text. This is not the case for things like OO languages where the behavior can depend on the context, or the order in which you declared things. I would say this is a defect of such languages, but I guess most people disagree with that idea.

Second, even in a functional language, one relies on a knowledge of the operational semantics. If I have two modules compiled against different language versions, I still expect to know what they denote, so there is no problem figuring out how to make them interoperate if all I'm interested in is the program result. But if the operational semantics are different, then things get more difficult, since essentially you will have two abstract machines running at once. So if the `parameter-passing conventions' changed (say, eager to lazy) then you may have genuine problems reckoning the algorithmic complexity of your programs, especially if you have a things like higher-order functions, since you cannot know in which module they originated, etc. This is a very good point.

doesn't scoping change the semantics of closures?

You mean like dynamic versus static scoping? That would be a non-conservative semantic change.

If we are talking about visibility, that's syntactic. But almost any syntactic change is going to change the semantics of a piece of source text. Indeed, the whole point of assigning language version numbers is that you can assign multiple semantics to identical source texts. The question is, rather, whether the denotational and operational semantics is `big enough' to accomodate all of them. You can sidestep this issue if there is a core language which all versions can be translated to.

For example, say version 1 is the language Scheme, and version 2 is Scheme except that the meanings of `car' and `cdr' are exchanged. (You would never want to do this, of course, but for the sake of example...) Then the source text

(let ((xs '(1 2))) (list (car xs) (cdr xs)))

will have the semantics '(1 2) in version 1, and the semantics '(2 1) in version 2. They're different but that's fine. What we care about is just that there is a way of comparing them. In this case it's easy to do: you can either translate version 1 programs to version 2 programs or vice versa.

Likewise, it doesn't matter if changing the scoping rules changes the semantics, as long as there's a common ground, or reference we can translate the different versions to.

yep.

i agree that syntax changes semantics (otherwise it's pointless), but my current working definition for "syntactic sugar" is that the changes are "local" to the sugar.

i was going to make the observation earlier, and your comment about common ground makes it obvious, that you can view virtual machines as the "kernel implementation". so different java syntax may need different java compilers, but these can be considered pre-processors that generate byte code which can be combined and compiled by the jvm. afaik the jvm spec has not changed (much) since 1.2 (1.5 is compatible with 1.4, i believe, despite the various new things being discussed in another thread). (wasn't there a thread about this recently?).

But everybody knows that the only parameter passing mechanism endorsed by Real Programmers is call-by-value-return, as implemented in the IBM/370 Fortran G and H compilers!

Sorry, I just couldn't resist ;-)

This turns out not to be the case. Syntactic issues are definitely a problem in any language that allows runtime compliation, and some syntactic things (such as scoping) may be an issue with any language that allows introspection. While not entirely common, changes in syntax can be quite an issue if a routine is dynamically building up source that gets passed into another routine for final processing and ultimate compilation. While not hugely common as a problem, mostly because I don't know of any language that allows both runtime compilation and multiple differing language definitions simultaneously, it is an issue that shouldn't be overlooked. Disallowed, perhaps, but not overlooked.

Actually JavaScript does allow this to an extent. You can mark JavaScript sections in HTML as compatible with a particular version of that language.

And then "livescript history"
Origins of JavaScript