Hey, sorry for the lack of response. I’ve taken a bit of time to read, think and experiment with ideas related to the topic.
After reading a lot about type-classes and re-visiting some previous threads in the overall discussion, I have come to realize that this proposal is not enough; it doesn’t give an adequate solution to the problems faced with type-classes in both Scala and Haskell.
Another thing I took note of in the overall discussion is the apparent confusion surrounding the conflation of the term context. It means one thing for type-classes – a set of compile-time constrains – and an entirely different thing for injection – ephemeral run-time shared data (similar to React’s context).
My conclusion to both of these is that the endeavor of making type-classes easy, fluent and useful in Scala should be separated (orthogonal?) from the “implicit features” (injection, extensions and conversions). It seems that the historical attempts to bend these features to make type-classes work is what causes a lot of misuse and confusion in the language. Type-classes deserve their own distinct syntax, constructs and rules.
I would like then to update my proposal to reflect that conclusion by making the “implication” feature even weaker:
- It should not be possible to
import imply(one can stillimportand thenimply). Importing and then implying values is hardly a common use-case for anything other than type-classes. - Definitely no context bounds, or at least detach the concept completely from “implicit” and associate it with the new type-class constructs.
- Do not allow for implied parameters with type-parameters (which is a bit of an irregularity, so I’m not entirely sold on that).
As for type-classes, I believe they should be explored someplace else. This has already been done, but not with the mind-set of differentiating them from implicits and giving them the solution to their own unique set of problems and use-cases instead of a generic abstraction over many unrelated concepts.
However, I do see some connection between type-classes, extensions and conversions, in the sense that they are all a set of compilation rules / hints / constraints that can be imported. I’d be tempted call this concept “lenses”, as in adding a lens on an optical scope (adding compilation constraints on a lexical / programming scope). Funny though, it seems that Haskell already managed to use this term for something else (ugh).