-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More granular hierarchy #56
Comments
Yeah, I am all for this. (Ideally, I’d say the type classes should have |
Ya I'm totally up for this for 3 reasons
|
Is worth having laws:
|
I'll have a think about the first one, but the second one seems like it might not always hold. E.g., if fmap point [1, 2, 3]
= [[1], [2], [3]]
/= [[1, 2, 3]]
= point [1, 2, 3] |
Ah good point! I was thinking of |
lmao https://wiki.haskell.org/Why_not_Pointed%3F
|
Seems like it's not as useful as I thought according to Kmett, so maybe it's best left out unless you can think of anything :) fwiw Kmett says the first law is a free theorem so that's all G 👌 |
Yeah, I’m sympathetic to wanting |
Ran into a roadblock when prototyping this work. We can't do One workaround is have |
Huh, I wonder why there isn't a "prefer" operator for types–like |
How would we feel about making the
Functor
hierarchy a little more granular? I.e. following PS's lead rather than Haskell's. We could go from:to:
The impetus for this issue is that when trying to address #52, it's worlds easier if we have
List/extend
/List/duplicate
.List
cannot be aComonad
(because there's no way to implementextract
).List
can be a very usefulExtend
though. There are many other data types that make greatApply
s/Bind
s/Extend
s that don't necessarily have the right structure to implementApplicative
/Monad
/Comonad
.The text was updated successfully, but these errors were encountered: