Samuel Vivien
Samuel Vivien
After some thinking I arrived at the conclusion that using value restriction was indeed the best direction to go. This could allow optimization with reduced module allocation and functor application....
The main problem is that if we have a non-blocking lambda, then the values `M(type t1).v` and `M(type t2).v` are physically equal. As such when computing the type of `r`...
On the same topic as keeping names : When doing unification we sometimes unify two unification variables together. However if only one out of both had a name we do...
In a similar way could we also add a `module functor E = F` This might be useful in some other cases and does not seem much work in addition...
A better argument against using underscore to talk about the beginning of the module is that current work on modular implicits. We are currently thinking of defining `_` as an...
As a whole I'm strongly in favor of this feature because I consider that it would increase the quality of life when handling tuples. I also find the part about...
Just a small comment to add more motivations for this proposal : I would be beneficial for modular implicits because it would help reduce the number of false ambiguities. I...
From what I remember from a discussion with @goldfirere we concluded that we didn't want to have the invariant : > The argument's type in a `Types.Tarrow` node must be...