[Builtins] Add detection of applied type variables to the elaboration machinery #4648
Conversation
|
You're breaking my heart Michael, I've rewritten that damn thing four times from scratch before becoming convinced it was the simplest way of handling the most general case. |
|
I didn't say it wasn't the simplest possible ;) |
| -- | Throw an error telling the user not to apply type variables to anything. | ||
| type ThrowNoAppliedVars :: (GHC.Type -> GHC.Type) -> GHC.Constraint | ||
| type family ThrowNoAppliedVars hole where | ||
| -- In the Rep context higher-kinded type variables are allowed, but need to be applied via |
There was a problem hiding this comment.
Perhaps add a See Note [Rep vs Type context] here in case someone finds the "Rep/Type context" terminology unfamiliar.
There was a problem hiding this comment.
Thanks, done.
| 'Text " applied via regular type application" ':$$: | ||
| 'Text "To fix this error instantiate all higher-kinded type variables" | ||
|
|
||
| instance TypeError NoRegularlyAppliedHkVarsMsg => Functor (Opaque val) where |
There was a problem hiding this comment.
It's nice to remove these specific instances. I assume you can do something similar to the TypeError NoConstraintsErrMsg => Eq (Opaque val rep) instance and similar ones?
There was a problem hiding this comment.
No, unfortunately. We can barf on any applied type variable, but we can't barf on any variable appearing in the argument position as it's perfectly fine to have an argument whose type is a type variable (as in IfThenElse). It's really about not allowing any constraints and for that the best we can do is hardcode some of them.
effectfully
force-pushed
the
effectfully/builtins/add-detection-of-higher-kinded-vars
branch
from
a22e01d to
79f3c58
Compare
…to effectfully/builtins/add-detection-of-higher-kinded-vars
effectfully
force-pushed
the
effectfully/builtins/add-detection-of-higher-kinded-vars
branch
from
79f3c58 to
177e942
Compare
effectfully
deleted the
effectfully/builtins/add-detection-of-higher-kinded-vars
branch
This:
TypecontextRepandTypecontexts and gives the user a more specific error message due to being context-awareI've tested it manually, gonna commit some example error message in a subsequent PR (I need a bit of additional machinery for that, hence a different PR).