Hacker News Reader

Comment by macrolime | Hacker News Reader

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

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.ht...

https://pchiusano.github.io/2013-09-10/type-systems-and-ux-e...

View on HN

This is fascinating. Thank you for linking to this.

Identified by its content how?

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.

Sounds like C++ name mangling.

No, because the mangled names still depend on the names ...

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.

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.

Ah, that makes it more clear.

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.

You presumed right, that's how it works ;)

I don't know why we keep reinventing this distribution model and failing at it, then trying again.

Bugfixing and identity matter.

Uh, could you explain more? Your comment doesn't really give any clues about what you are complaining about.

Reply on news.ycombinator.com