git-merge-driver VS unison

You could make a custom merge driver for the conflicting file: https://github.com/Praqma/git-merge-driver

I investigated the option of using a custom git merge driver for a project where we were planning to version control a bunch of data files using git.

Here's a proof of concept python merge driver I bashed together at the time to auto-merge JSON objects: https://github.com/fcostin/jsonmerge_git_merge_driver

This never went anywhere near production, but it was very easy to put together something basic.

One complication with using a custom merge driver, as discussed by https://github.com/Praqma/git-merge-driver , is that they need to be configured inside the `.git/config` of the repo, which itself is not version controlled. So there's an additional config management overhead to rolling that out to everyone in a machine. Additionally, if outsourcing hosting for git repos, it may not be supported to install and configure a custom merge driver for merges conducted by the hosting platform (e.g. merges created by github.com pull request workflow).

One idea I had at the time was using external schema files (e.g. JSON schema for JSON files) to help guide/constrain the result of the merge. I never implemented it, but it should be possible. If the schemas were also version controlled in the same git repo that stores the data, you'd need to figure out which one (and which version) to load when resolving a merge conflict of a data file. There doesn't seem to be a well-supported robust way for a merge driver script to discover the source and destination branches, but there are some potentially fragile ways of doing it that work some of the time.

Short version: no type classes (yet)

Longer version:

Building upon what Quekid5 mentioned, Unison abilities are an implementation of what is referred to as algebraic effects in programming language literature. They represent capabilities like IO, state, exceptions, etc. They aren't really a replacement for type classes, though in some cases you can shoehorn abilities in where you might otherwise use a type class.

For someone coming from a Haskell background, I think that abilities are closer to a replacement for monad transformers. But in my opinion they are much more ergonomic.

Discusson of type classes comes up a lot. Here is a long-standing GitHub issue: https://github.com/unisonweb/unison/issues/502

For what it's worth, I've written Unison quite a lot over the past few years and while I've missed type classes at times, I think that reading unfamiliar code is easier without them. There's no implicit magic; you can see exactly what is being passed into a function. So far I've been happy with a bit more verbosity for the sake of readability.

I've been following the Unison lang [1] for quite some. Wing seem to set similar goals? From the first glance Wing looks more polished, but there's "The Big Idea" behind Unison - is there something similar?

[1]: https://github.com/unisonweb/unison

in haskell it looks like this, you specify the language extensions you want at the top of the source files: https://github.com/unisonweb/unison/blob/trunk/unison-core/src/Unison/ABT.hs

they adjusted my ticket to be a bug fix on their part.

I think Unison is going in this direction. Imo this is a mistake, as a program language functions not just as specification for the machine, but also as communication between programmers. Allowing the introduction of arbitrary dialects to suit individual preferences seems like it would interfere with that communication.