Add OnionN[N <: Nat]

[fanf]

The general use case is to be able to specify what depth of the onion stack you want to use as the correct return type of a step.

This is needed to be able to use an Onion stack with more than one layers, but for steps where the last layers are actually part of the business type (typically, a List, Option, Either or some other data containers) and should not be part of the monad transformer stack.

An example is available here: https://gist.github.com/fanf/845273a15377347a04375d51a0139b78 See also thread: https://twitter.com/mandubian/status/765809870734028800

[mandubian]

@fanf Can you precise a bit?

type O = Foo :&: Bar :&: Toto :&: Nil
Foo[Bar[List[Option[A]]].OnionN[_2, O]
// should OnionN seek in depth in type O or in type Foo[Bar[List[Option[A]]] ?

Last weekend, I've tried to simplify onionT vs onionP but I think it's impossible to get rid of that. It's the same as liftT & lift.

[fanf]

Ah. This is exactly my wondering, to. I believe that as an user (ie I don't know it it's possible), what I want is:

• my type O is what I want to normalise to, i.e the type of each line (the returned type of the whole program)
• for each line, I want to be able to "help" freek and let it knows that the type of the line should be explored N level deep only (or perhaps more robustly to traverse all and go back N levels as in "keep the last N containers").

Not sure it helps.

[fanf]

Well, what I know is that in classical for { } yield { }, I'm accustomed to normalise to Xor[E, T]. So I want to make the really common use case (for me):

for {
  a     <- myService1() // Xor[E, A]
  list_b <- myService2(a)  //Xor[E, List[B]]
  opt_c  <- Xor.right(pure()) // with pure: Option[C]
  res   <- calculus(list_b, opt_c)  // calculus(l: List[B], opt: Option[C]): Xor[E, D]
} yield {
  res
}

To be portable in freek with the onion type explaining to future use what the program is about, i.e:

type O = Xor[E, ?] :&: Bulb

And whatever is needed to help scalac use the correct implicits - of course the leaner the better.

Hope it's clearer

[mandubian]

now you would have to write something like:

type O = Xor[E, ?] :&: Bulb
for {
  a     <- myService1().onionT[O]
  list_b <- myService2(a).onionP[O]
  opt_c  <- (()).onionT[O]
  res   <- calculus(list_b, opt_c)  // calculus(l: List[B], opt: Option[C]): Xor[E, D]
} yield {
  res
}

going further with implicits poses problems as soon as you encounter something like

for {
  a     <- myService1()
  list_b <- myService2(a)
  opt_c  <- ().onionT[O]
  res   <- optc match {
    case Some(c) => ...
    case None => ...
   }
   // scalac is enable to unify types in the for-comprehension and you have to help it
} yield {
  res
}

[fanf]

OK, what about if calculus returns a Xor[E, List[D]]? (because of course, you're right, the problem in my use case is in the last returned type...)

[mandubian]

yep that' s the case I was speaking about... the important isn't only the O but what you want to keep in your Xor[E, List[D]]...

Xor[E, List[D]].onionN[O, 1] would take Xor[E, List[D]], dig one layer in depth, keep List[D] and lift it into the onion O.

but I think this onionN can't be generalized...

[fanf]

@mandubian

yep that' s the case I was speaking about... the important isn't only the O but what you want to keep in your Xor[E, List[D]]...

Xor[E, List[D]].onionN[O, 1] would take Xor[E, List[D]], dig one layer in depth, keep List[D] and lift it into the onion O.

That would be perfect!

but I think this onionN can't be generalized...

Oh :/

[fanf]

Is it simpler if onionN[O, 1] consume the full stack and then drop one layer ? (no because it's the most external layer which is easely dropped ?)

[mandubian]

which full stack, the one you give in input or the onion?

[fanf]

the input

[mandubian]

actually if you look at package.scala, for now, I had to create an implicit conversion for every stack F[A], F[G[A]], F[G[H[A]]]... so I feel OnionN isn't so easy for now ;)

[fanf]

oOOHHHhhoo. What a lib dev has to do to let the user think things are nice :))

[pvillega]

What @fanf said, but I understand it may not be feasible :)