nvim-treesitter-context VS unison

Very cool! Sort of reminds me of treesitter-context. Any chance for compatibility? An example could be you either would disable context when something is pinned or somehow displace it other, depending on which is "on top" could be neat.

It's for context and navigation, not completions. So it wouldn't replace nvim-cmp. It probably doesn't replace anything you already have unless you are already using a winbar. It combines features of treesitter-context, symbols-outline, and a file navigator but in a different presentation.

Not quite the same thing, but arguably a better alternative : https://github.com/nvim-treesitter/nvim-treesitter-context

For 2: https://github.com/nvim-treesitter/nvim-treesitter-context

I really like nvim-treesitter-context as an alternative for 1.

nvim-treesitter-context implements "sticky scroll" where, depending on where your cursor is placed, the top lines of your window will be replaced by the otherwise offscreen lines that declare what function you're in (e.g function test(...), the line that begins the current class (e.g. public class Student implements Person {), the variable name of the current table (e.g. local planets = {), etc.

Very different in my eyes, but I love nvim-treesitter-context. Definitely another tool in helping the brain parse code -- I think of it as helping with long range context, whereas blockman helps me focus on local context and makes scoping relationships more subconciously available.

You are looking for this: https://github.com/nvim-treesitter/nvim-treesitter-context

I have seen https://github.com/nvim-treesitter/nvim-treesitter-context is recommended, and it works similar. But the way the context info are displayed in AstroNvim is much nicer

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.