101–110 of 134 posts
This is really exciting. I might have missed this in the documentation, but is there any way of grouping/tagging together a set of functions, just so that conceptually similar functions can be browsed together? For traditional languages a folder/package/file performed this functionality.
Earlier quoted context omitted.
> Storing the AST on the disk in a million files is not necessarily the best use of the filesystem A new codebase format just uses a sqlite database instead of a million files > Since the language is append only, all edits look like additions in version control Traditional methods of showing change in verson control, that is text diffs, don't make sense here anyway > Detecting that 2 things are the same through hashi…
What's the point of detecting that 1 + x + 1 is the same as x + 2 anyway? If I wrote it in one way, I meant it to be that way for a reason. Should it also be able to prove arbitrary code is semantically equivalent? Well, it can't do that for obvious reasons.
Hashing was created to prevent collisions and ensure small changes have big differences in result. The first requirement makes sense here, but not sure how the second helps.
I had a really hard time wrapping my mind around this just reading the website alone. If you are in the same boat, watch the first 10 minutes of this video at 1.5x speed: https://www.youtube.com/watch?v=gCWtkvDQ2ZI and it will make so, so much more sense. ...and if you are like me you'll probably need to read this twitter thread to get the answer to your #1 question: https://twitter.com/unisonweb/status/1173942974381…
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…
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 generic "library" functions like `List.map`).
We already make this distinction for data types, but not yet for value/function definitions.
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” which contains an integer. In version 1 of my library, this integer must be even, but in version 2 I add support for odd integers, too. The Foo data type, from a content perspective, is unchanged. However, the invariants around it have changed and it’s therefore essential that it becomes a new type. Otherwise, someone might create a Foo containing an odd integer using the version 2 API and then pass it to a function from the version 1 API, resulting in bad things since the version 1 API believes Foo can never contain an odd integer.
I had a really hard time wrapping my mind around this just reading the website alone. If you are in the same boat, watch the first 10 minutes of this video at 1.5x speed: https://www.youtube.com/watch?v=gCWtkvDQ2ZI and it will make so, so much more sense. ...and if you are like me you'll probably need to read this twitter thread to get the answer to your #1 question: https://twitter.com/unisonweb/status/1173942974381…
Earlier quoted context omitted.
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…
SemVer remains a pragmatic approach that works in vast amount of cases. It’s unclear what alternative we have here which works in more cases.
> A friendly programming language from the future. It looks like a programming language from the present at best. A programming language from the future would have finally broken free from the prison of plain text.
Look a little closer. This is not a graphical programming language, but it's definitely not "plain text" either.
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.
I had a really hard time wrapping my mind around this just reading the website alone. If you are in the same boat, watch the first 10 minutes of this video at 1.5x speed: https://www.youtube.com/watch?v=gCWtkvDQ2ZI and it will make so, so much more sense. ...and if you are like me you'll probably need to read this twitter thread to get the answer to your #1 question: https://twitter.com/unisonweb/status/1173942974381…
Earlier quoted context omitted.
Good explanations, but I'm always a little suspicious when I see things like this: > Code is stored as a structured, type-checked tree in a database, not as text in files What does everyone think a filesystem is?
I'm not sure I understand your question. Could you elaborate?
They mention using git to version Unison code, and point out how there'll practically never be any version conflicts because of the immutable / append-only nature of the language. Doesn't that mean that the git repository will only ever grow, and that old code will stick around forever? I hope I'm misunderstanding because that would be unfortunate if true.
What I don't understand is what they do when merging two branches. If both branches introduce a function with the same name a merge conflict is inevitable, no? Or do they not support the distributed version control approach and every developer has to submit their changes to the current version of the database?