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

Add OnionN[N <: Nat] #5

Open
fanf opened this Issue Aug 22, 2016 · 13 comments

Comments

Projects
None yet
3 participants
@fanf
Contributor

fanf commented Aug 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mandubian

mandubian Aug 22, 2016

Owner

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

Owner

mandubian commented Aug 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@fanf

fanf Aug 22, 2016

Contributor

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.

Contributor

fanf commented Aug 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@fanf

fanf Aug 22, 2016

Contributor

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

Contributor

fanf commented Aug 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mandubian

mandubian Aug 22, 2016

Owner

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
}
Owner

mandubian commented Aug 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@fanf

fanf Aug 22, 2016

Contributor

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

Contributor

fanf commented Aug 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mandubian

mandubian Aug 22, 2016

Owner

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

Owner

mandubian commented Aug 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@fanf

fanf Aug 22, 2016

Contributor

@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 :/

Contributor

fanf commented Aug 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@fanf

fanf Aug 22, 2016

Contributor

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 ?)

Contributor

fanf commented Aug 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mandubian

mandubian Aug 22, 2016

Owner

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

Owner

mandubian commented Aug 22, 2016

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

@fanf

This comment has been minimized.

Show comment
Hide comment
@fanf

fanf Aug 22, 2016

Contributor

the input

Contributor

fanf commented Aug 22, 2016

the input

@mandubian

This comment has been minimized.

Show comment
Hide comment
@mandubian

mandubian Aug 22, 2016

Owner

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 ;)

Owner

mandubian commented Aug 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@fanf

fanf Aug 22, 2016

Contributor

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

Contributor

fanf commented Aug 22, 2016

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

@pvillega

This comment has been minimized.

Show comment
Hide comment
@pvillega

pvillega Aug 22, 2016

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

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

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