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

Move some derivations into coresponding algebras #188

Open
safareli opened this issue Oct 22, 2016 · 3 comments
Open

Move some derivations into coresponding algebras #188

safareli opened this issue Oct 22, 2016 · 3 comments

Comments

@safareli
Copy link
Member

Currently this are derivations separately from algebras but I think we can move them to algebras:

  • map may be derived from bimap => BiFunctor
  • map may be derived from promap => ProFunctor
  • map may be derived from traverse => Traversable
  • reduce may be derived from traverse => Traversable
  • map may be derived from ap and of => Applicative
  • map may be derived from chain and of => Monad
  • ap may be derived from chain => Chain

As discussed in #179 we should at least state that <*> = ap in Apply and Chain (or Applicative and Monad) but we should also investigate if other derivations should be moved to corresponding algebras.

@bergus
Copy link
Contributor

bergus commented Oct 27, 2016

Ah, I wanted to just ask the same. My confusion was especially about Bifunctors, because stating that map can be derived from bimap (or that "Bifunctor needs to implement Functor") isn't enough, it would also need to say how. Is a.map = f => a.bimap(f, identity) (not .bimap(identity, f)) a valid Functor? The laws say yes, but e.g. in Haskell it doesn't work to make Mydatatype a b to be a Functor over a.
Speaking of which, Haskells Bifunctor doesn't state that second ≡ map, although it would make sense to me (and I haven't found counterexample implementations). Could there be a reason for the omission?

@safareli
Copy link
Member Author

safareli commented Oct 28, 2016

The list in this issue is just an outline of derivations we have. if we move them into algebras we should also show default derivation.

In case of bimap, in derivations we have map = function(f) { return this.bimap(a => a, f); } and this will work in haskell too as it's deriving map from last parameter (second).

I have just taken look at bimap and indeed there is no word about map being equal to second and as i said:

we should investigate if other derivations should be moved to corresponding algebras

One thing i know is that <*> = ap is for sure a law and others need investigation.

@rpominov
Copy link
Member

rpominov commented Oct 30, 2016

Maybe what we should do is:

  • Remove statement "If a data type provides a method which could be derived, its behaviour must be equivalent to that of the derivation (or derivations)".
  • Start adding laws that we're sure about (currently only <*> = ap as far as I understand), and keep adding as we find more.
  • At the same time keep all derivations in place, including ap. There is no harm in having them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants