Kinds update#157
Conversation
MatthijsBlom
requested review from
konsumlamm,
memowe,
pierluc-codes,
smith558,
ulysses4ever and
xogcox
as code owners
pierluc-codes
left a comment
pierluc-codes
left a comment
There was a problem hiding this comment.
small detail to fix. thank you!
| Woot, that works! | ||
| We see two new things here. | ||
| First, `Constraint` is the kind of constraints, i.e. the things that appear to the left of the `=>` in type signatures. | ||
| The `Ord Int` instance, for instance, has kind `Constraint`. |
There was a problem hiding this comment.
This is a little bit imprecise: the instance is the implementation that satisfies the constaints. It's Ord Int itself that has kind Constraint, not the instance.
There was a problem hiding this comment.
Of course 🤦
I think I confused myself by thinking of the implicitly passed dictionary, and by considering constraints singleton 'types'.
| Now, to make this type a part of `Functor` we have to partially apply the first two type parameters so that we're left with `* -> *`. | ||
| That means that the start of the instance declaration will be: `instance Functor (Barry a b) where`. | ||
| Now, to make this type a part of `Functor` we have to fill the first two parameters so that we're left with `* -> *`. | ||
| That means that the start of the instance declaration will be: `instance Functor (Barry … …) where`. |
There was a problem hiding this comment.
Any reason for the ellipsis?
There was a problem hiding this comment.
The same names a and b are used for something else in the very next sentence. Justification for using c and d instead would come only after this sentence, which felt a bit weird, and without justification it would be arbitrary. Using something felt too heavy / noisy. I considered using _, but that being valid syntax might lead to some confusion. In the end I figured I'd try and see how reviewers would feel about …. It's the shape of the instance type that is the point; arbitrary variable names need no drawing attention to.
|
( Lemme squash the feedback commits before merging please. ) |
2 participants
GHC 9.6.7 (currently recommended by GHCup) uses
GHC2021as the default language, which includesPolyKinds.This renders the
:kindoutput shown in the book out of date.I include an additional section on
:k Functorbecause I feel it helps ground the rest of the discussion. With it,Functor's requirements are no longer only to be inferred, but also plain to see in the output of:k.The
[Char]↦Stringchange is included because GHCi gives the latter (because string literals are used in the input).