Arc Forumnew | comments | leaders | submitlogin
Backward compatability by translation?
2 points by Darxus 5778 days ago | 1 comment
1) It would be good for Arc's development if it always freely broke backward compatibility.

2) It would be nice if I could use Arc for my daily work.

3) But it would be nice to have a reasonable way to keep all my code running on the latest version of Arc.

So I'm thinking it would be neat if, every time backward compatibility was broken somewhere, a bit of code to translate from the old version to the new version were written.

And then the Arc version were mentioned at the beginning of any bit of Arc code.

And then the interpreter, upon parsing such version information, would load the translator from the previous version to the current version. And if the code was written in a version before that, it would load the next translator in the line.

So say you have code written for Arc 3.1, and you have Arc 3.6 installed, and all releases have been incremented by 0.1.

Interpreter sees that the code is older than itself, loads latest translator, written for it. 3.5 -> 3.6, written in 3.6. Code is still older. 3.4 -> 3.5, written in 3.5, which is fine because I just loaded that translator. 3.3 -> 3.4 3.2 -> 3.3 3.1 -> 3.2, Matches! So the code then gets translated from 3.1 to 3.2. Then you start over again and it gets translated from 3.2 to 3.3.

Kind of.. not straightforward, but I think possibly a useful way to maintain the advantages of breaking backward compatibility freely, and maintaining backward compatibility.

Obviously it would be nice if this translating mess could output translated code.

I'm not claiming this would be easy. But I think it would be nice. In a way that could significantly increase adoption. Which could significantly increase development.

This text box is too small, vertically.



2 points by aw 5776 days ago | link

I've upgraded my code on every Arc release since arc0, and it's been easy.

This may sound overly simple compared to building a translator, using namespaces or modules, or writing in layered API's, but in practice this is what quickly results in working code for me: in my source code file, I merely arrange my definitions so that definitions that depend on other definitions always appear after the definitions that they depend on.

For example, if h uses g and g uses f, I write out the definitions with the lowest level code appearing in the file first: f, then g, and then h.

(On occasion I'll have mutually recursive functions; those I'll just put next to each other in the source code file. And when I have multiple source code files, I follow the same principle: I ensure that I can order the source code files so that later files depend on code in earlier files, but no earlier files depend on code in later ones).

Now it is simple to upgrade the code in my source code file to a new version of Arc: first I get f to work, then I get g to work, and then I get h to work.

Each step is quick: most often the function doesn't need a changes to work in the new version of Arc, and if a change is needed it's just a tweak.

No massive monolithic all-at-once conversion needed.

And there's no pressure. My code still works with the previous version of Arc that it is running on. So I can convert over to the new version at my leisure. When I'm ready.

Even if someone wrote a translator, I wouldn't use it myself. It would add an extra layer of complexity (if I have a bug, is it in the new version of Arc, or in my code, or in the translator?), and I wouldn't need it.

-----