- A language that transpiles down to human readable, idiomatic Go.
- Automatic folding of normal Go code into more concise/functional-style syntax.
- Proper preservation of where every folded token came from for byte-perfect reconstruction of the original code. (Probably involving something like a lockfile).
- On-demand transpilation during VCS checkout, or transpilation can happen directly in your IDE during file load/save.
I think as long as some tricks are done, the in-IDE transpilation could even let you reuse all the existing Go syntax highlighting and autocompletion IDE infra.
I started working on an IDE plugin to prototype transpilation "Go -> new lang". The plugin would replace Go code using IDE "code-folds" so it effectively didn't exist and wouldn't impact autocomplete/highlighting. And then you could use IDE snippets that expand to Go code to "pretend" you were writing in the new language.
But unfortunately, I have too many other wild dreams in my head so it never went anywhere.
I wonder if you could cheat by insisting the original code must have been run through an opinionated formatter so there's a One True Represenation of the source and you can restrict the problem to byte-perfect reconstruction of -that-?
(I have the same dream too sometimes and keep wondering if that would, at least, be a more tractable goal for a version 0.1 if I ever get a round tuit)
But it still sounds totally doable!
The only thing I can think of that did is the Interlisp-D editing functionality provided by Interlisp Medley, where your code was stored within the system as parsed S-expr trees and when you opened an editor onto something it reverse engineered a textual expression of the thing according to your configuration.
Tagging every, single, node, with enough data to recreate the indentation and formatting seems theoretically doable, and if you're wanting to let people edit things that are, say, config file shaped, then you're going to have to do that if you want the resulting commit diffs to be sufficiently coherent that people will be willing to use it.
But taking the Medley approach for a first attempt/first release feels a lot more doable, and given the biggest obstacle to such a thing is almost certainly congruent to "being able to make a start over a weekend for the sheer fun of it" I think it's well worth considering :D
What about the other direction? I don't think it will be very useful to not be able to read the exact code you wrote after the fact. Feels like writing a book but every sentence you enter is instantly rephrased by ChatGPT to sound more convoluted.
That would mean pulling from git would get you code that’s harder to read than what you pushed (if that’s not the case, you wouldn’t have used that transpiler)
There also isn’t agreement on the common subset.
For example, scala has lazy sequences, Rust wants programmers to have control over memory deallocation, go (sort-of) requires threads to have small stacks, Swift has copy-on-write collections, python’s numbers automatically become bignums, many languages really need efficient boxing to have efficient implementations, etc.
Strip all that, and you end up with WASM (or, possibly, even something even smaller), and various language ecosystems would build libraries on top of that that are incompatible with each other (possibly sometimes in non-obvious ways, leading to hard to detect bugs)