Skip to content
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

Open
joneshf opened this issue Feb 3, 2019 · 10 comments
Open

More granular hierarchy #56

joneshf opened this issue Feb 3, 2019 · 10 comments
Labels
Open Source Labelling open source contributions

Comments

@joneshf
Copy link
Contributor

joneshf commented Feb 3, 2019

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:

old

to:

new

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 a Comonad (because there's no way to implement extract). List can be a very useful Extend though. There are many other data types that make great Applys/Binds/Extends that don't necessarily have the right structure to implement Applicative/Monad/Comonad.

@sellout
Copy link
Contributor

sellout commented Feb 3, 2019

Yeah, I am all for this. map2 (aka liftA2), join, and duplicate are the semigroup operation of the Applicative, Monad, and Comonad (co)monoids, respectively. And ap, bind, and extend can be defined in terms of those semigroup operations, so it’s a reasonable separation.

(Ideally, I’d say the type classes should have map2, join, and deplicate as their operations, with the others derived, but reasonable people differ.)

@FintanH FintanH added the Open Source Labelling open source contributions label Feb 4, 2019
@FintanH
Copy link
Contributor

FintanH commented Feb 4, 2019

Ya I'm totally up for this for 3 reasons

  1. It will make defining dhall-bhat in terms of kind-poly easier
  2. Can document as we split out these main pieces
  3. You're dead right about functionality around extend and duplicate

@FintanH
Copy link
Contributor

FintanH commented Feb 7, 2019

Is worth having Pointed as well? The graph above would be Applicative <- (Pointed, Apply)

laws:

  • fmap f . point === point . f
  • fmap point === point

@joneshf
Copy link
Contributor Author

joneshf commented Feb 7, 2019

I'll have a think about the first one, but the second one seems like it might not always hold. E.g., if point :: a -> [a] then:

fmap point [1, 2, 3]
  = [[1], [2], [3]]
  /= [[1, 2, 3]]
  = point [1, 2, 3]

@FintanH
Copy link
Contributor

FintanH commented Feb 7, 2019

Ah good point! I was thinking of Optional when I was riffing on it.

@FintanH
Copy link
Contributor

FintanH commented Feb 7, 2019

lmao https://wiki.haskell.org/Why_not_Pointed%3F

(he still provides the pointed package only because “people were whinging”).

@FintanH
Copy link
Contributor

FintanH commented Feb 7, 2019

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 👌

@sellout
Copy link
Contributor

sellout commented Feb 7, 2019

Yeah, I’m sympathetic to wanting Pointed, but it ends up being “Default in the category of endofunctors”.

@FintanH
Copy link
Contributor

FintanH commented Feb 8, 2019

Ran into a roadblock when prototyping this work.

We can't do Applicative f //\\ Bind f because they share fields. We also can't project fields for type records :(

One workaround is have Monad/Type be defined as Bind f //\\ { pure : forall(a : Type) -> a -> f a }

@joneshf
Copy link
Contributor Author

joneshf commented Feb 8, 2019

Huh, I wonder why there isn't a "prefer" operator for types–like // for terms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Open Source Labelling open source contributions
Projects
None yet
Development

No branches or pull requests

3 participants