You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using kindc as the type checker for Bend does work to an extend, correctly checking the functions, but the unification algorithm is quite limited in what it can infer, needing a great deal of help with annotations or by breaking things in smaller chunks.
For kind users that is not such a big problem, since they get full access to the underlying type system, but for Bend a lot of the problematic things come from the compilation process itself, either from generated functions/terms or from the conversion of Bend to kindc.
It would be bad UX if Bend users also needed to understand the limitations of the kindc checker. So I decided it'd be better to instead implement our own actual HM type system which, since it's much more restricted in what it can do, doesn't hit the same issues.
Directly writing the type system in the bend codebase was a bit too hard since it has too many things already that need to be taken care of to even compile the most basic things.
So I decided it'd be better to first implement it in a separate repo and after I had the basic stuff down I'd port it back to Bend. Writing it directly in Rust was also a bit hard since most (legible, well-structured) implementations use a very functional style. Rust also needs a lot more boilerplate which hurt the legibility that I needed to learn how HM works and how to implement it.
I'm first implementing it in haskell in that same repo, then converting things to Rust and then finally to Bend.
#615 describes the need for having a type system for Bend as well as the design discussion of how this system should be.
This issue tracks the implementation of the bend type system.
The text was updated successfully, but these errors were encountered: