Add OnionN[N <: Nat] about freek

[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]

@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.

[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 :)