3 ms·

I have this same dream wayyy too often (uunfortunately). - A language that transpiles down to human readable, idiomatic Go. - Automatic folding of normal Go c

I have this same dream wayyy too often (uunfortunately). - 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.

mst 2y ago
> Proper preservation of where every folded token came from for byte-perfect reconstruction of the original code. 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)
- nulld3v 2y ago
  That is a really intriguing idea! Not sure if Go has exactly the sort of tool you are talking about, `go fmt` still allows for some minor differences, and I believe the same applies to `gofumpt` as well. But it still sounds totally doable!
  - mst 2y ago
    Right, even the most opinionated of modern formatters don't go quite that far. 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

mst 2y ago

> Proper preservation of where every folded token came from for byte-perfect reconstruction of the original code. 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)

nulld3v 2y ago
That is a really intriguing idea! Not sure if Go has exactly the sort of tool you are talking about, `go fmt` still allows for some minor differences, and I believe the same applies to `gofumpt` as well. But it still sounds totally doable!
- mst 2y ago
  Right, even the most opinionated of modern formatters don't go quite that far. 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