3 ms·
Last time I looked, [Unison code] -> [entry in the AST DB] was a one-way process. Adding a function means writing it (with whatever style you like) and seeing
by __MatrixMan__ 2y ago
Last time I looked, [Unison code] -> [entry in the AST DB] was a one-way process. Adding a function means writing it (with whatever style you like) and seeing if what you wrote constitutes a new function or an existing one. You can't fluff db entries back up in to human friendly code.
I don't see why it couldn't be done though, I think it just hasn't been a priority. Heck, you could have 100 different users collaborating in 100 different "languages", and so long as they serialized to the same AST and back, none of them would ever have to see the atrocious syntax which the other users prefer. Their editors and browsers could just render everything according to their users' preferences.
Edit: it appears that Unison has an issue for this feature: https://github.com/unisonweb/unison/issues/499 https://github.com/unisonweb/unison/issues/499
- tkzed49 2y agoif they were truly represented by the same AST, I can't believe the differences between these "languages" would be anything more than swapping symbols out.
- __MatrixMan__ 2y agoTrue. Perhaps "styles" or "syntaxes" would be better. It's all that stuff we spend time building consensus around, but that doesn't affect program behavior. If our tools respected our style preferences on a user-by-user basis, we could drop the consensus requirement altogether.