4 ms·

While I agree with the argument that it’s better to let the semantics drive the formatting, I wish we could get over formatting discussions already, with the co

While I agree with the argument that it’s better to let the semantics drive the formatting, I wish we could get over formatting discussions already, with the codebase recording the structure, and the displayed format being a matter of editor configuration. Tabs, spaces, linewidths, whatever... knock yourself out. A bonus would be if vcs patches/diffs are semantically aware. Has this ever been tried seriously? Given their simple syntax, one of the lisps seem to be the best poised to drive this change.

fiddlerwoaroof 6y ago
There are various tools for this: I believe one of the interns at Jane Street wrote a tool to diff s-expressions, and similar tools exist for lisp source code. Ultimately, the issue is that tooling is mostly made to be programming-language independent, which makes it hard for this sort of tooling to succeed
- ulrikrasmussen 6y ago
  I think making a tool like that language independent is impossible. You have to start by making it a diff tool just for tree structured data (diff tools today are special cases of this as they operate on list based data). You then need to extend it to work on specific languages by diffing "modulo equations", e.g. in Haskell two top-level definitions are allowed to commute, so `x = e; y = f` should be considered identical to `y = f; x = e`. But I think that's fine. The diff tool should use the most specific diff mode that it knows is safe, and fall back to the "free diff" of tree structured data when working on an unknown language.
  - fiddlerwoaroof 6y ago
    I looked into using tree-sitter as a bar for this once: parse code into an AST of sorts and then use the ast to define the diff boundaries. Didn’t think through all the problems, though
UrsaMedius 6y ago
You might be interested in Unison, where you edit code in text but let the manager/runtime handle the storage. It changes how you need to work with VCS quite a lot. https://www.unisonweb.org/ https://www.unisonweb.org/ Also Dhall, a configuration language, generates hashes for semantics so if you refactor something you can check that the hash is unchanged to know that the function is unchanged. https://dhall-lang.org/ https://dhall-lang.org/

fiddlerwoaroof 6y ago

There are various tools for this: I believe one of the interns at Jane Street wrote a tool to diff s-expressions, and similar tools exist for lisp source code. Ultimately, the issue is that tooling is mostly made to be programming-language independent, which makes it hard for this sort of tooling to succeed

ulrikrasmussen 6y ago
I think making a tool like that language independent is impossible. You have to start by making it a diff tool just for tree structured data (diff tools today are special cases of this as they operate on list based data). You then need to extend it to work on specific languages by diffing "modulo equations", e.g. in Haskell two top-level definitions are allowed to commute, so `x = e; y = f` should be considered identical to `y = f; x = e`. But I think that's fine. The diff tool should use the most specific diff mode that it knows is safe, and fall back to the "free diff" of tree structured data when working on an unknown language.
- fiddlerwoaroof 6y ago
  I looked into using tree-sitter as a bar for this once: parse code into an AST of sorts and then use the ast to define the diff boundaries. Didn’t think through all the problems, though

UrsaMedius 6y ago

You might be interested in Unison, where you edit code in text but let the manager/runtime handle the storage. It changes how you need to work with VCS quite a lot. https://www.unisonweb.org/ https://www.unisonweb.org/ Also Dhall, a configuration language, generates hashes for semantics so if you refactor something you can check that the hash is unchanged to know that the function is unchanged. https://dhall-lang.org/ https://dhall-lang.org/