Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unison Programming Language

unisonweb.org

Post reply on HN
Print view View original

111–120 of 134 posts

Re: The Unison Programming Language

#111

Post by refried_ »

jbrot wrote: post #104

Very neat project! One question about content addressed programs: how does this play out with types that are structurally equivalent but semantically distinct? For instance, assuming C definitions, an integer and a file descriptor have the same content but probably should not be treated as the same type (I wouldn’t want arithmetic to type check against file descriptors…). Another scenario: say I have a type “Foo” whi…

The language has "unique" types, meaning they have their own semantic meaning apart from their structure; they get a unique hash (currently implemented by adding a random salt to the hash of the structure, though it might as well be a guid). So "unique" types and "structural" types.

The same question came up for terms, here: https://news.ycombinator.com/item?id=27654045

Re: The Unison Programming Language

#112

Post by jbrot »

refried_ wrote: post #111
jbrot wrote: post #104

Very neat project! One question about content addressed programs: how does this play out with types that are structurally equivalent but semantically distinct? For instance, assuming C definitions, an integer and a file descriptor have the same content but probably should not be treated as the same type (I wouldn’t want arithmetic to type check against file descriptors…). Another scenario: say I have a type “Foo” whi…

The language has "unique" types, meaning they have their own semantic meaning apart from their structure; they get a unique hash (currently implemented by adding a random salt to the hash of the structure, though it might as well be a guid). So "unique" types and "structural" types. The same question came up for terms, here: https://news.ycombinator.com/item?id=27654045

Glad to hear there’s a solution for this! Thanks for responding :)

Re: The Unison Programming Language

#113

Post by modernerd »

xpe wrote: post #94
torginus wrote: post #40

Earlier quoted context omitted.

I'm not totally convinced by this. - Storing the AST on the disk in a million files is not necessarily the best use of the filesystem. In contrast, most languages store text files on the disk, and build up a similar AST in memory only - You can't view your code without special tools, which means all text editors/version control etc. need to be Unison-aware - Since the language is append only, all edits look like addi…

Semver is an uneasy compromise at best. Rich Hickey has a nice talk that digs into the principles around changing software. Once you see this POV, you are unlikely to view Semantic Versioning as anything other than a messy hack. I'm not saying it is worse than nothing, but sometimes ideas have a way of sticking around too long and making people comfortable.

The talk for those interested: https://youtube.com/watch?v=oyLBGkS5ICk

Re: The Unison Programming Language

#114

Post by vanderZwan »

refried_ wrote: post #103
dcposch wrote: post #36

Earlier quoted context omitted.

Cool to see people thinking this big! One challenge I foresee is unintentional coupling. Say you have two functions: func serialize(MyRecord) ... func debugToString(MyRecord) ... Now if you ever make the mistake of having giving those the same implemention, then in Unison they'd be the same hash reference, right? Then if you want to update, say the debug print later it would update all callsites for that hash includi…

Hello, Unison author here. This is definitely an issue that is real, and is currently a problem, and that we will fix; probably by giving the function author an option to salt the hash of new definitions that have some semantic meaning beyond their implementations (appropriate for most application/business logic). No salt for definitions whose meanings are defined by their implementations (appropriate for most generi…

Why not also show that your definition already exists elsewhere, together with with a warning? Or is it doing that too?

Re: The Unison Programming Language

#116

Post by TuringTest »

steve_taylor wrote: post #107
lolinder wrote: post #93

Earlier quoted context omitted.

Look a little closer. This is not a graphical programming language, but it's definitely not "plain text" either.

I looked a little closer and found this: Unison is a language in which programs are not text. That is, the source of truth for a program is not its textual representation as source code, but its structured representation as an abstract syntax tree. This document describes Unison in terms of its default (and currently, only) textual rendering into source code. Or to put it more concisely, Unison is currently a plain-t…

That's akin to saying that machine code is not binary but plain text, because Assembler exists.

It is more accurate to say, Unison is an AST language which nowadays happens to have just one human-readable interface, which is text.

Re: The Unison Programming Language

#117

Post by vanderZwan »

torginus wrote: post #41
umvi wrote: post #25

Earlier quoted context omitted.

That's basically what the twitter thread I linked explains. It sounds like there is an automatic propagation mechanism for updating downstream callers if the type hasn't changed, otherwise it sounds like a manual update process.

Sounds like trading one set of problems for another.

Tangent: here's what I find fascinating: when we evaluate which algorithm or data structure is best to handle a given situation, we know how to reason about algorithmic complexity and pick a best option for our situation.

But then when it comes to ideas like this we just tend to say "we're trading one set of problems or another", as if we can't evaluate the problems in a similar manner. And I'm not picking on you here, I tend to do the same!

Yes, we're trading one set of problems for another, but what if the old set of problems was "O(n²)" and the new set of problems is "O(nlog(n))"? Or maybe it's the other way around. Why isn't it obviour how to apply those earlier skills here?

Re: The Unison Programming Language

#118

Post by uncomputation »

lamontcg wrote: post #56
torginus wrote: post #51

Earlier quoted context omitted.

You are right - but choosing the correct solution imho needs to be done with human oversight - I think a semver based dependency resolution works great here, for example if bar requires foo 1.0 and baz needs 1.0.1 they will happily use the same version, but if baz used foo 1.1 they would use the separate ones.

Except 1.0.1 can fix a bug that one piece of code needs, while another piece of code can be happily bug dependent upon it. You can scream at the developers that they've violated semver but a "bugfix" is entirely subjective (relevant xkcd, spacebar heating, etc). And even when developers violate semver in a point release the problem still exists. They actually rarely, if ever, rollback with a 1.0.2 that is equivalent…

(Mentioned xkcd: https://xkcd.com/1172/)

Re: The Unison Programming Language

#119

Post by xpe »

dang wrote: post #58

The past threads appear to be (others?): Unison: A Content-Addressable Programming Language - https://news.ycombinator.com/item?id=22156370 - Jan 2020 (12 comments) The Unison language - https://news.ycombinator.com/item?id=22009912 - Jan 2020 (141 comments) Unison – A statically-typed purely functional language - https://news.ycombinator.com/item?id=20807997 - Aug 2019 (25 comments) Unison Language March Update - ht…

Also, to go a little further back, Joe Armstrong talked about content-addressable code in a conference talk:

“The Mess We're In” by Joe Armstrong at Strange Loop [video] - https://news.ycombinator.com/item?id=8342755 - Sep 2014 (77 comments)

Re: The Unison Programming Language

#120

Post by xpe »

brundolf wrote: post #7

> Unison definitions are identified by content. Each Unison definition is some syntax tree, and by hashing this tree in a way that incorporates the hashes of all that definition's dependencies, we obtain the Unison hash which uniquely identifies that definition. Very cool core concept. Reminds me of some things Rich Hickey has said about the idea of versioning dependencies at the function level That said: I wonder if…

Yes, Rich Hickey (a bit more systematic) and Joe Armstrong (a bit more scattershot) have popularized some of these ideas.

I'd be very interested in learning about analagous static analysis tools for referentially transparent languages / purely functional languages with sufficiently expressive type systems. Please share what you find :)

Post reply on HN