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

replace all inconsistent fold methods with switch #1466

Closed
fommil opened this Issue Sep 21, 2017 · 10 comments

Comments

Projects
None yet
4 participants
@fommil
Contributor

fommil commented Sep 21, 2017

e.g. Validated.fold

another one for #1463

Obvs for scalaz8... but what do people think about doing this in the next 7 series?

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Sep 21, 2017

What do you mean by inconsistent?

@fommil

This comment has been minimized.

Contributor

fommil commented Sep 21, 2017

i.e. not matching the signature of Foldable.fold

At at the Fantasyland Advanced FP training today and we just learnt that cata is more correct 😄

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Sep 21, 2017

I'm not sure that cata is a great name for Validation#fold:

def fold[X](fail: E => X, succ: A => X): X

It doesn't literally follow the pattern

class DataStructure[F[_]] {
  def cata[X](f: F[X] => X)(implicit F: Functor[F]): X
}

(If you squint enough, it somewhat does: if you take type F[X] = E \/ A and instead of F[X] => X handle the cases E and A separately; but that's quite a stretch IMO.)

I think it is much more intuitively just case analysis, so what do people think about calling it switch?

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Sep 21, 2017

In other words, even if catamorphism does generalize case analysis, we would be appealing to a much more general concept than is necessary, to no benefit.

@fommil fommil changed the title from replace all inconsistent fold methods with cata to replace all inconsistent fold methods with switch Sep 23, 2017

@jdegoes

This comment has been minimized.

Member

jdegoes commented Sep 25, 2017

I talk about making generic deconstructors and deconstructors in this post, where I also adopt the (somewhat familiar) name switch for deconstruction.

I'm not too picky on the precise names, but I do think we need pervasive consistency across each version of Scalaz to make learning the library easier and more predictable.

Btw if you want to see the catamorphism, just take F[X] = E \/ A. Now the function f that performs the "fold" must handle E if it's a failure, and A if it's a success, and the implementation of cata can produce an X in only one of two ways (either by feeding f an E, or by feeding it an A).

Things get more interesting with a list, in which case you take F[X] = () \/ (A, X), i.e. the function f that performs the "fold" must handle () if it's an empty list, and (A, X) if it's a cons cell (so the implementation of cata must obtain the initial X from the terminal Nil, and then work backwards over each element of the list to produce the final X).

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Sep 26, 2017

👍 for consistency. Also, I think it's fine to have both cata and switch and have them do the same thing. I just think switch (or caseAnalysis or handleCases or cases) is more accurate in this case.

@fommil fommil added this to the 7.3.0 milestone Oct 9, 2017

@fommil fommil self-assigned this Oct 22, 2017

@NeQuissimus

This comment has been minimized.

Member

NeQuissimus commented Nov 21, 2017

@fommil I was about to open this for Scalaz 8. Are you looking to provide a solution that would be transferable? A "Switchable" type class or whatever you come up with :) \/.fold and Maybe.fold are my primary use cases here...

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Nov 22, 2017

What would the Switchable type class look like? The pattern is not limited to binary sums.

@NeQuissimus

This comment has been minimized.

Member

NeQuissimus commented Nov 22, 2017

I did not exactly think this through :D. But Maybe.fold and Disjunction.fold have been used quite frequently in our code bases and I was simply wondering if that could be properly formalized.

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Nov 22, 2017

These two folds can have a common interface because Maybe[A] is isomorphic to Unit \/ A. But how about sums of other arities?

@jdegoes jdegoes added this to To Spec in Scalaz 8 Nov 28, 2017

@jdegoes jdegoes moved this from To Spec to To Do in Scalaz 8 Nov 28, 2017

@jdegoes jdegoes moved this from To Do to To Spec in Scalaz 8 Nov 28, 2017

@jdegoes jdegoes removed this from To Spec in Scalaz 8 Nov 28, 2017

@fommil fommil modified the milestones: 7.3.0, 8.0.0 Dec 16, 2017

@fommil fommil added scalaz7 and removed scalaz7 labels Jun 17, 2018

@fommil fommil modified the milestones: 8.0.0, 7.3.0 Jun 23, 2018

@fommil fommil removed their assignment Aug 23, 2018

@fommil fommil closed this Sep 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment