3 ms·

I have an idea for maintaining backwards compatibility in programming languages. Why not support old features of the language in the new version of the compile

I have an idea for maintaining backwards compatibility in programming languages. Why not support old features of the language in the new version of the compiler/interpreter? This seems to be particularly feasible in Lisp/Scheme family of languages due to the fact that ASTs are edited directly in source code. For example, each library declares its target version of the compiler, then newer compiler first translates the library to new syntax, then integrates it with other dependencies. What's wrong with this line of thought?

neilv 3y ago
Good thought. Racket does this and more, for a long time. For the "more": you can do it not only for other dialects of the same language, but also for very different languages. And often to make them interoperable between languages. (For one simple example, long ago I made a fairly simple `#lang sicp` that translates the old dialect of MIT Scheme used by the SICP book, to Racket, using some simple syntax transformation and the module system.)
grapehut 3y ago
It's often not that simple. As a concrete example, I think Golang made a giant mistake with 'nil interfaces' ( e.g. https://go.dev/tour/methods/12 https://go.dev/tour/methods/12 ) which can lead to extremely confusing and weird code ( e.g. https://go.dev/play/p/Qk1g9tSwQcw https://go.dev/play/p/Qk1g9tSwQcw ). So let's assume there was wide spread consensus that it's a terrible idea and it should work like every other programming language. There is really no obvious way to simply "convert to the new syntax"? And trying to have "go with nil interfaces" library interact with "go with normal type system" would be it's own can of worms. Like in this case, the only realistic path I could see would be you deprecate it, then you start warning, and then in like 10 years or something you fully remove it?
layer8 3y ago
It still breaks compatibility for the library maintainers, and the results of automatic translation often aren’t pretty (as a basis for further development). It’s also difficult to test or prove that the automatic translation is 100% correct on arbitrary code. Furthermore, as a sibling comment notes, some language changes are made virtually impossible, even with source code translation, if backwards compatibility needs to be maintained. Sometimes there is really no substitute for getting things right from the start.
- ducktective 3y ago
  But Scheme languages are particularly simple in terms of their syntax and logic to the point that it is often said people write more scheme compilers than scheme libraries. I thought it would be possible to deterministically translate R^(n-1)RS to R^(n)RS

neilv 3y ago

Good thought. Racket does this and more, for a long time. For the "more": you can do it not only for other dialects of the same language, but also for very different languages. And often to make them interoperable between languages. (For one simple example, long ago I made a fairly simple `#lang sicp` that translates the old dialect of MIT Scheme used by the SICP book, to Racket, using some simple syntax transformation and the module system.)

grapehut 3y ago

It's often not that simple. As a concrete example, I think Golang made a giant mistake with 'nil interfaces' ( e.g. https://go.dev/tour/methods/12 https://go.dev/tour/methods/12 ) which can lead to extremely confusing and weird code ( e.g. https://go.dev/play/p/Qk1g9tSwQcw https://go.dev/play/p/Qk1g9tSwQcw ). So let's assume there was wide spread consensus that it's a terrible idea and it should work like every other programming language. There is really no obvious way to simply "convert to the new syntax"? And trying to have "go with nil interfaces" library interact with "go with normal type system" would be it's own can of worms. Like in this case, the only realistic path I could see would be you deprecate it, then you start warning, and then in like 10 years or something you fully remove it?

layer8 3y ago

It still breaks compatibility for the library maintainers, and the results of automatic translation often aren’t pretty (as a basis for further development). It’s also difficult to test or prove that the automatic translation is 100% correct on arbitrary code. Furthermore, as a sibling comment notes, some language changes are made virtually impossible, even with source code translation, if backwards compatibility needs to be maintained. Sometimes there is really no substitute for getting things right from the start.

ducktective 3y ago
But Scheme languages are particularly simple in terms of their syntax and logic to the point that it is often said people write more scheme compilers than scheme libraries. I thought it would be possible to deterministically translate R^(n-1)RS to R^(n)RS