3 ms·

Well, a few days ago there was a post about the Unison language, where code is stored in AST form and text is just a representation. https://news.ycombinator.c

Well, a few days ago there was a post about the Unison language, where code is stored in AST form and text is just a representation. https://news.ycombinator.com/item?id=40882133 https://news.ycombinator.com/item?id=40882133

__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 ago
  if 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 ago
    True. 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.
KMag 2y ago
I've long dreamt of a system that compiles to native code, but stores a compressed SSA form (similar to SafeTSA or LLVM bitcode) in the binary for efficient runtime re-optimization based on profiling, somewhat similar to current Android Runtimes. One could then have several levels of debugging symbols, one that gives names to local variables represented by CFG nodes, and another that adds a compressed diff between some standardized decompiler output and the original source. You could then decompile to some alternative syntax, but you'd lose any idiosyncratic formatting represented by the compressed diff.
- zeusk 2y ago
  You mean Java or .NET?
  - KMag 2y ago
    I'm not aware how to get byte-for-byte identical source out of a Java class file or .NET assembly. Last I checked, Java AoT compilation precluded runtime re-optimization, though I presume they've fixed that by now. Last I checked, they both used stack-based bytecode, which typically takes longer to JIT and results in slower native code than a compressed SSA / control flow graph (see the SafeTSA papers).
- neonsunset 2y ago
  .NET assemblies are that :) Though SSA is deferred to JIT/ILC instead. In either case you get the access to all the actual low-level bits when you need to. No other portable target lets you do that.
  - KMag 2y ago
    If you add an extra blank line, or add a trailing space to a line, can you really get that back out from a .NET assembly? Normal disassembly at a minimum results in a loss of formatting.

__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 ago
if 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 ago
  True. 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.

KMag 2y ago

I've long dreamt of a system that compiles to native code, but stores a compressed SSA form (similar to SafeTSA or LLVM bitcode) in the binary for efficient runtime re-optimization based on profiling, somewhat similar to current Android Runtimes. One could then have several levels of debugging symbols, one that gives names to local variables represented by CFG nodes, and another that adds a compressed diff between some standardized decompiler output and the original source. You could then decompile to some alternative syntax, but you'd lose any idiosyncratic formatting represented by the compressed diff.

zeusk 2y ago
You mean Java or .NET?
- KMag 2y ago
  I'm not aware how to get byte-for-byte identical source out of a Java class file or .NET assembly. Last I checked, Java AoT compilation precluded runtime re-optimization, though I presume they've fixed that by now. Last I checked, they both used stack-based bytecode, which typically takes longer to JIT and results in slower native code than a compressed SSA / control flow graph (see the SafeTSA papers).
neonsunset 2y ago
.NET assemblies are that :) Though SSA is deferred to JIT/ILC instead. In either case you get the access to all the actual low-level bits when you need to. No other portable target lets you do that.
- KMag 2y ago
  If you add an extra blank line, or add a trailing space to a line, can you really get that back out from a .NET assembly? Normal disassembly at a minimum results in a loss of formatting.