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

51–60 of 134 posts

Re: The Unison Programming Language

#51

Post by torginus »

lamontcg wrote: post #47
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…

Loading both copies of a library can be very useful to deal with the situation where one piece of code has been ported to v2 (due to bugs/features or just generally keeping up with updates) and another piece of code is hard blocked on the v1->v2 migration because it is much more costly, and its possible that v2 is actually buggier for that other use case. There's a bit of a naive idea that software always gets better…

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.

Re: The Unison Programming Language

#52

Post by ajuc »

lamontcg wrote: post #50
ajuc wrote: post #26

Earlier quoted context omitted.

Nope, according to https://twitter.com/unisonweb/status/1173942969726054401 when you change a function implementation the system has to walk the callers graph backwards starting from all the places where the function was called updating all the implementations with the new hash, then callers of these with the new implementation and so on up to main (or whatever it's called). I had a chance to implement something like…

A git-like datastore for your AST+callgraph.

Let's say you have definitions like that:

    f: Nat -> Nat
    g: Nat -> Nat
    h: Nat -> Nat
    h x = g (x * 2)
    g x = f (x * 3)
    f x = x
And now you change f to be

    f x = x
How do you do that? There's a cycle in the callgraph. In fact - how do you calculate a hash of a function that calls itself if you need its hash to calculate its hash :)

EDIT: nevermind, recursion is a special case handled differently.

Re: The Unison Programming Language

#53

Post by refried_ »

ajuc wrote: post #32

This is like maven at function level with no SNAPSHOT versions allowed :) How is recursion handled? To get a hash for a function you have to have hashes for every function it calls. Is there special "recurse" opcode? And how do you update a function implementation when you have a cycle in the callgraph?

Yes to Maven, and good questions.

Simply put, there is a special recurse opcode.

When you have a cycle in the call graph, they all get hashed together as a single unit; you update them together as a single unit too.

Re: The Unison Programming Language

#54

Post by lisper »

gbhn wrote: post #33
lisper wrote: post #21

Earlier quoted context omitted.

No. The name of a function in current languages has no connection at all to what the function does. (What would be the contract for a function named ‘foo’?)

That's kind of the thing that makes APIs possible, right? It sounds to me like "what if programming were done in a completely flat global namespace in which abstractions, encapsulation, and structure were impossible."

No. An API specifies more than the name of the function. It will specify the arguments, their types, the type of the return value, and at least informally, what the function does. You can change the underlying implementation without changing the API. That's the whole point of an API. The problem with current API technology is that the informality of the spec of what the function does. That allows some aspects of the behavior of the function to change without triggering any warnings.

By having the linker work on hashes of implementations you eliminate that problem but create a new problem. You can no longer change the behavior of the function because you can't change the function. That means you can't suddenly change behavior that some caller is counting on, but it also means you can't fix bugs without changes in the caller.

Re: The Unison Programming Language

#55

Post by jack_h »

turtletontine wrote: post #43
turtletontine wrote: post #34

Earlier quoted context omitted.

I'm not totally sure what the important distinction is here. For many languages the important thing is already a post-parsing data structure, that's what any compilation output or byte code is. You obviously want to keep the raw source around as well if you're the developer. Nothing new about having separate source code and compiled formats?

Update: I'm skimming here ( https://jaredforsyth.com/posts/whats-cool-about-unison/ ) and here ( https://joshondesign.com/2012/04/09/open-letter-language-des... ) and I see Unison is serious about not having raw text source code as the ground truth. I'm intrigued but don't totally understand yet. I'm sure this analogy is technically incorrect but: This reminds me of Smalltalk and old Lisps on mainframes shared by man…

Perhaps see my reply here (https://news.ycombinator.com/item?id=27654225).

I think you may be misunderstanding what is being stored here. Now as a caveat I'm not familiar with this language, but I am familiar with the concept as described. They are not removing source code, rather source code is stored after some processing; in this case it appears to be after lexing, parsing, and type checking. I'm not sure exactly what is being stored, i.e. an AST, but it sounds like they're basically moving this stage of compilation/interpretation to be much earlier in the process.

I'm assuming this database can be queried and the result can be rendered back to a textual presentation as well. Presumably this opens the door for syntax being divorced from language semantics since how the syntax is parsed into the database and how the database is rendered into text can be a client side decision rather than set in stone inside the compiler/interpreter. What is set in stone is the semantics of the database that everyone must agree to.

Again, there's the caveat that I'm not familiar with how this language in particular is implementing this concept.

Re: The Unison Programming Language

#56

Post by lamontcg »

torginus wrote: post #51
lamontcg wrote: post #47

Earlier quoted context omitted.

Loading both copies of a library can be very useful to deal with the situation where one piece of code has been ported to v2 (due to bugs/features or just generally keeping up with updates) and another piece of code is hard blocked on the v1->v2 migration because it is much more costly, and its possible that v2 is actually buggier for that other use case. There's a bit of a naive idea that software always gets better…

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 to 1.0.0 and instead usually move forwards.

And if you have a language that supports loading 1.0 and 1.1 then there's no point in being artificially constrained over which two versions can be loaded at the same time based on the label, the underlying framework shouldn't be built to care. There's no need for a multi-version library loader to care about what a bugfix is.

Re: The Unison Programming Language

#57

Post by prezjordan »

Strongly encourage anyone reading this to take 20 minutes to download ucm and run through the Getting Started guide: https://www.unisonweb.org/docs/quickstart/

Programming with a codebase manager and a scratchpad is just so much fun - I found myself hypnotized and came back an hour later with some janky min heap code. Definitely seems to scratch an itch for me.

Re: The Unison Programming Language

#58

Post by dang »

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 - https://news.ycombinator.com/item?id=19528189 - March 2019 (1 comment)

Large-scale, well-typed edits in Unison, and reimagining version control - https://news.ycombinator.com/item?id=9708405 - June 2015 (11 comments)

Unison: a next-generation programming platform - https://news.ycombinator.com/item?id=9512955 - May 2015 (128 comments)

Re: The Unison Programming Language

#59

Post by brundolf »

dthul wrote: post #38

An immediate caveat I came across: if you want to look at some Unison code you need a special code management tool. Take for example their base library on Github: https://github.com/unisonweb/base The actual code lives in a sqlite file in the .unison/v2 folder. That would mean existing tools like version control and editors would need to learn about how Unison works in order to seamlessly support it. Also pulling out…

This is an interesting choice. Any language or framework has to make a dozen or more choices between doing something in a way that's compatible but compromising, or bespoke but... bespoke. It's always a painful choice in my experience. This one is particularly bold, though.

Re: The Unison Programming Language

#60

Post by __david__ »

This looks like a neat idea—I can see upsides and downsides, but would have to experiment to see if one outweighs the other.

One thing I didn't see in my (admittedly quick) perusal of the tutorial and faq: what is the technique to run a Unison program from the command line? Is it practical for making unix cli tools (yet)?

Post reply on HN