5 ms·

The Unison language stores code as a syntax tree and they're planning to support multiple alternative syntaxes for the language. https://www.unisonweb.org http

The Unison language stores code as a syntax tree and they're planning to support multiple alternative syntaxes for the language. https://www.unisonweb.org https://www.unisonweb.org Unison’s core idea is that code is immutable and identified by its content. This lets us reimagine many aspects of how a programming language works. We simplify codebase management — Unison has no builds, no dependency conflicts, and renaming things is trivial. Some blog posts by the author of the language describing a bit of background https://pchiusano.github.io/2013-05-22/future-of-software.html https://pchiusano.github.io/2013-05-22/future-of-software.ht... https://pchiusano.github.io/2013-09-10/type-systems-and-ux-example.html https://pchiusano.github.io/2013-09-10/type-systems-and-ux-e...

slver 5y ago
Identified by its content how?
- auggierose 5y ago
  Hashing, like in Git I guess built-in things get fixed names / hashes, and the hashes of everything else follow from that. They need a mapping from content/hashes to human-friendly names, obviously. Not sure if they gained anything here, but they seem to think so, so might be worth checking this out.
  - slver 5y ago
    I don't know why we keep reinventing this distribution model and failing at it, then trying again. Bugfixing and identity matter.
    - fzzzy 5y ago
      Uh, could you explain more? Your comment doesn't really give any clues about what you are complaining about.
  - tyingq 5y ago
    Sounds like C++ name mangling.
    - auggierose 5y ago
      No, because the mangled names still depend on the names ...
      - tyingq 5y ago
        Not sure I get the distinction. Hashes "depend" on the name as well. You perhaps can't (easily) unmangle, but it's still a derivation.
        lisper 5y ago
        I am not really familiar with Unison, but I presume it works like this: Only the code itself is hashed. The then-current name is then added as an annotation. When you refer to a name, the language compiler looks up the hash currently associated with that name and stores the hash instead of the name. When code is rendered, the name associated with the hash at render-time is looked up and displayed. That way if the name is changed, all of the renderings generated after that automagically use the new name. It's actually quite a clever idea.
        asoltysik 5y ago
        You presumed right, that's how it works ;)
        breuleux 5y ago
        From what I recall from looking at Unison not long ago, the hashes do not depend on names. `f x = x * x` and `g y = y * y` both have the exact same hash and are considered to be the exact same function. Any call to `f` or `g` will be stored as a call to their hash, so `f2 x = f (x + 1)` and `g2 x = g (x + 1)` would also have identical hashes. This does appear to pose a small issue for types, since isomorphic types are identical regardless of their names, but I believe they have a way to attach a unique id to enforce a distinction.
leephillips 5y ago
This is fascinating. Thank you for linking to this.

slver 5y ago

Identified by its content how?

auggierose 5y ago
Hashing, like in Git I guess built-in things get fixed names / hashes, and the hashes of everything else follow from that. They need a mapping from content/hashes to human-friendly names, obviously. Not sure if they gained anything here, but they seem to think so, so might be worth checking this out.
- slver 5y ago
  I don't know why we keep reinventing this distribution model and failing at it, then trying again. Bugfixing and identity matter.
  - fzzzy 5y ago
    Uh, could you explain more? Your comment doesn't really give any clues about what you are complaining about.
- tyingq 5y ago
  Sounds like C++ name mangling.
  - auggierose 5y ago
    No, because the mangled names still depend on the names ...
    - tyingq 5y ago
      Not sure I get the distinction. Hashes "depend" on the name as well. You perhaps can't (easily) unmangle, but it's still a derivation.
      - lisper 5y ago
        I am not really familiar with Unison, but I presume it works like this: Only the code itself is hashed. The then-current name is then added as an annotation. When you refer to a name, the language compiler looks up the hash currently associated with that name and stores the hash instead of the name. When code is rendered, the name associated with the hash at render-time is looked up and displayed. That way if the name is changed, all of the renderings generated after that automagically use the new name. It's actually quite a clever idea.
        asoltysik 5y ago
        You presumed right, that's how it works ;)
      - breuleux 5y ago
        From what I recall from looking at Unison not long ago, the hashes do not depend on names. `f x = x * x` and `g y = y * y` both have the exact same hash and are considered to be the exact same function. Any call to `f` or `g` will be stored as a call to their hash, so `f2 x = f (x + 1)` and `g2 x = g (x + 1)` would also have identical hashes. This does appear to pose a small issue for types, since isomorphic types are identical regardless of their names, but I believe they have a way to attach a unique id to enforce a distinction.

leephillips 5y ago

This is fascinating. Thank you for linking to this.