131–134 of 134 posts
Earlier quoted context omitted.
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.
Go takes an alternative approach: https://www.youtube.com/watch?v=wWApoImHuf8
It doesn't contradict SemVer.
However when you do that, it becomes a big deal to jump from one version to another even if the breaks are minor. So pros and cons.
This looks pretty well done. It doesn’t seem like a gimmick; they’ve made a lot of good choices beyond the core conceit of content-addressable code. One thing I didn’t see skimming the language reference page: is there any sort of typeclass mechanism?
No, but it’s planned; probably in the form of implicit parameters.
My guess is yes, since that would probably forbid modifying the instance, since we would now have both the new and old copy. Unless of course we couple type class instances with the definition of the type itself (or the definition of the class) and view the type together with all its instances as a unit (as Unison does with mutually recursive functions), but that would bring on its own set of issues.
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…