Feature/witherable

[raveclassic]

Part #485
Adds:

• Witherable typeclass
• default implementations for witherDefault and wiltDefault (?) should we add them?
• withered and wilted functions
• default implementation for Traversable's traverse via Witherable (?) should we add it?

Updates:

• Traversable signature

Deprecates:

• satellite traverse function in favor of split Traversable.traverse which accepts instances separately

[gcanti]

default implementations for witherDefault and wiltDefault (?) should we add them?

I'd say no (same as with Filterable)

default implementation for Traversable's traverse via Witherable (?) should we add it?

Idem, I'd say no

withered and wilted functions

Each of them has 35 (!) overloadings and they are a trivial application of wilt/wither, I think we should avoid them.

Witherable typeclass
Traversable signature

Interesting, you are using a new technique which I'd like to talk about further. I'm a bit concerned by the number of overloadings, I have no idea of its possible impact on compilation times / quick info service

[gcanti]

Other observations

• if your your technique works well with Witherable we could apply it to Traversable too, and we could deprecate Travsersable.traverse
• some overloadings in Wither{1,2,3,2C,3C}<W> / Wilt{1,2,3,2C,3C}<T> are defined twice
• if I understand how it works, Wither<W> / Wilt<T> look useless and Witherable<T> should define only one version

export interface Witherable<T> extends Traversable<T>, Filterable<T> {
  /**
   * Partition a structure with effects
   */
  wilt: <F>(F: Applicative<F>): <RL, RR, A>(
    wa: HKT<W, A>,
    f: (a: A) => HKT<F, Either<RL, RR>>
  ) => HKT<F, Separated<HKT<W, RL>, HKT<W, RR>>>

  /**
   * Filter a structure  with effects
   */
  wither: <F>(F: Applicative<F>): <A, B>(ta: HKT<W, A>, f: (a: A) => HKT<F, Option<B>>) => HKT<F, HKT<W, B>>
}

[raveclassic]

Well, removing all default implementations together with wilted and withered makes this PR useless because I can't think of any other possible usage of Witherable typeclass (yet) :)

New signature for Wilt/Wither (actually not new, similar was used for sequenceT in Apply) was introduced to reuse it in Witherable methods and witherDefault/wiltDefault return types, so it's also redundant.

Traversable signature was only extended to be fully polymorphic for Applicative as well (previous implementation always used HKT<F, A>, and now it works with all kinds: Type, Type2 and Type3).

Summing up, looks like the only thing changed is Traversable which is handy IMO. Should I push it in another PR or it's ok to leave it here and clean the rest up?

[gcanti]

I can't think of any other possible usage of Witherable typeclass (yet)

purescript-filterable defines instances for

• Array
• StrMap
• Option
• Either

which are interesting (at least for Array, StrMap)

actually not new, similar was used for sequenceT in Apply

kind of, in sequenceT was used in the return type, here is in a type class definition (actually I'm a bit surprised that it works...)

Traversable signature was only extended to be fully polymorphic for Applicative as well

Yes and that's pretty nice, you didn't use the same encoding of Witherable though, I would expect something like

export interface Traverse1<T extends URIS> {
  <F extends URIS3, FU, FL>(F: Applicative3C<F, FU, FL>): <A, B>(
    ta: Type<T, A>,
    f: (a: A) => Type3<F, FU, FL, B>
  ) => Type3<F, FU, FL, Type<T, B>>
  <F extends URIS3>(F: Applicative3<F>): <FU, FL, A, B>(
    ta: Type<T, A>,
    f: (a: A) => Type3<F, FU, FL, B>
  ) => Type3<F, FU, FL, Type<T, B>>
  <F extends URIS2, FL>(F: Applicative2C<F, FL>): <A, B>(
    ta: Type<T, A>,
    f: (a: A) => Type2<F, FL, B>
  ) => Type2<F, FL, Type<T, B>>
  <F extends URIS2>(F: Applicative2<F>): <FL, A, B>(
    ta: Type<T, A>,
    f: (a: A) => Type2<F, FL, B>
  ) => Type2<F, FL, Type<T, B>>
  <F extends URIS>(F: Applicative1<F>): <A, B>(ta: Type<T, A>, f: (a: A) => Type<F, B>) => Type<F, Type<T, B>>
}

export interface Traversable1<T extends URIS> extends Functor1<T>, Foldable1<T> {
  traverse: Traverse1<T>
}

[raveclassic]

Ok, I'll update Traverable with new encoding and push. Instances will be added in the next PR then

[gcanti]

IME 3C must go after 3, and 2C after 2 otherwise typescript might pick the wrong overloading

[raveclassic]

I've never faced problems with the order, but ok I'll change

[gcanti]

Alas I did, that's why all overloadings in fp-ts follow the pattern

• 3
• 3C
• 2
• 2c
• 1