Agda VS lean

Most of the proof assistants out there: Lean, Coq, Dafny, Isabelle, F*, Idris 2, and Agda. And the main concepts are dependent types, Homotopy Type Theory AKA HoTT, and Category Theory. Warning: HoTT and Category Theory are really dense, you're going to really need to research them.

Does this come with plans to separately unify the body with each of the contexts induced by matching on each of the respective patterns (similar to what’s discussed here), or will it behave like the _ pattern and use only the most general context?

Coq, Agda, Lean, Isabelle, and probably some others which are not coming to my mind at the moment, but those would be considered the major ones.

Funny that you say this, because there are some obvious long standing open feature requests with looking up the type of the term under cursor — № 4295 and № 516. I am not blaming anyone in particular — this is the way it is. I wish I could find time to rewrite the proof search engine (how hard can it be), but I am already buried under a pile of other commitments and a good chunk of overwhelming sadness.

"Haskal is a mess, that's why I use a language that's written with Haskal."

Do it in Agda.

Agda is fun[1]. And there's also Idris[2] - more programming language, less proof assistant.

[1] https://wiki.portal.chalmers.se/agda/pmwiki.php https://github.com/agda/agda

At the most extreme level, you disappear into a meditative solitary retreat for a couple of years to seek enlightenment, and when you emerge you're no longer a programmer who writes programs, you're a theorist who proves theorems in Agda, and you have transcended above things that are tainted by the inherent evil of the material plane like "side effects" and "business needs" and "delivery timelines" and "could you stop doing that fancy math crap and just change the button's color like I asked for".

(For example, the standard dependent pair definition Σ, which is defined in Agda's core, does not have any).

However, mathlib makes some weird design choices. For example, (semi)groups are defined using multiplicative notation -- and then immediately followed by an entire section giving the exact same definitions using additive notation! The claimed reason for this is that the more abstract approach is inconvenient for automation. I did it in Coq using the abstract approach, and indeed, noticed that doing so broke automation, which I then worked around in various ways. But it's just weird to me as a mathematician to have additive and multiplicative groups be different objects, so I wouldn't want to do it the Lean way come hell or high water. The Lean approach causes practical difficulties as well: you have to prove every theorem about groups twice. In some cases (e.g. product groups), you have to prove every theorem FOUR times. Ugh.