Replies: 7 comments 55 replies
-
|
I think there was a wide consensus that this was a good idea.
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's basically the motivation for |
Beta Was this translation helpful? Give feedback.
-
|
Also, |
Beta Was this translation helpful? Give feedback.
-
|
Well, it's not actually source compatible in my proposed encoding: |
Beta Was this translation helpful? Give feedback.
-
|
How about |
Beta Was this translation helpful? Give feedback.
-
|
I've grown increasingly wary of aliasing data types over the years: I don't think |
Beta Was this translation helpful? Give feedback.
-
|
To the 😕ers, it's not so much that Also, put a |
Beta Was this translation helpful? Give feedback.
-
|
Leaving this here object one {
def t[A](r: Resource[IO, Option[A]]): OptionT[Resource[IO, *], A] =
OptionT(r)
def foo =
OptionT(
Resource
.make(IO.println("open A"))(_ => IO.println("close A"))
.as(Option.empty[Int])
)
def bar =
OptionT(
Resource
.make(IO.println("open B"))(_ => IO.println("close B"))
.as(10.some)
)
def baz =
foo <+> bar
def v = baz.value.use_.unsafeRunSync()
}
object two {
def t[A](r: Resource[IO, Option[A]]): Resource[OptionT[IO, *], A] =
r.mapK(OptionT.liftK).evalMap(opt => OptionT.fromOption[IO](opt))
def foo =
Resource
.make(IO.println("open A"))(_ => IO.println("close A"))
.as(Option.empty[Int])
def bar =
Resource
.make(IO.println("open B"))(_ => IO.println("close B"))
.as(10.some)
def baz =
t(foo) <+> t(bar)
def v = baz.use_.value.unsafeRunSync()
}
scala> one.v
open A
open B
close B
close A
scala> two.v
open A
open B
close B
res1: Option[Unit] = Some(())The second behaviour might be a bug in cats-effect |
Beta Was this translation helpful? Give feedback.
-
|
ow. That looks bad. cc @djspiewak |
Beta Was this translation helpful? Give feedback.
-
|
This is the |
Beta Was this translation helpful? Give feedback.
-
|
back to this, #2 prints in 3.2.9 :) |
Beta Was this translation helpful? Give feedback.
-
I just hit this limitation. Are you suggesting that there is a correct way (in 0.23.x) to reliably close resources acquired during producing |
Beta Was this translation helpful? Give feedback.
-
|
I think this would be a great improvement, and as a related matter, middlewares being "just Kleisli" is also problematic - an exception deep down in the stack won't be processed "on the way out" by middlewares above it, as they only deal with responses, but this is both surprising and difficult to deal with. If routes (and middlewares) could only produce requests/responses and not be allowed to throw unhandled exceptions like that it would be a lot more intuitive and less error prone than what we have today. That's in addition the very scary looking type errors that pop out when new team members change something incorrectly, of course. |
Beta Was this translation helpful? Give feedback.
-
|
Related to this, I think most folks agree that a good way to flat the learning curve of the typelevel ecosystem is using |
Beta Was this translation helpful? Give feedback.
-
|
Looking at #6740, I am in agreement with dealiasing HttpApp and HttpRoutes, but in disagreement with the details, particularly the hardcoding of Request as the input and Response as the output. Being able to compose and as plain functions is a major part of http4s' appeal. When we hardcode the inputs and outputs, we:
I think Kleisli has been unfairly maligned, particularly by demonstrably false performance claims, but I concede that it is unduly prominent in the API. The bare minimum a server needs in 0.23 is
|
Beta Was this translation helpful? Give feedback.
-
|
An example that is both a monad and knows about request and response is Haskell's Snap. That's an "innovative HTTP monad" that handles fallthrough, context, and resources, but I think would not fit with MTL middleware... nor the partial functions that most of our users write. I think it could compile to the same shape, though. |
Beta Was this translation helpful? Give feedback.
-
|
So, that's another direction I was thinking about, a RoutesIO type a la doobie, and that's why I asked
However, and I don't yet have an airtight argument as to why, I prefer Resource to be visible. I'll take a closer look at Snap's internals though, haven't used it in ages |
Beta Was this translation helpful? Give feedback.
-
|
Conjecture: all current middleware can be expressed with:
With I think we'd get the following support:
Monad[Function1] exists, but I think would only work for pure synchronous services. (Nobody is writing There would be Monad[RoutesIO] and maybe MonadResource[RoutesIO], but the output is the context, not the response. RoutesIO could only participate in middleware after "compilation". (This makes sense: a RoutesIO could be introspectable, and middleware generally defeats introspection.) RoutesIO is neat, but probably a side project in the space of a Rho or Endpoints4s. |
Beta Was this translation helpful? Give feedback.
-
|
I very much hope we don't need a
yeah fair enough |
Beta Was this translation helpful? Give feedback.
-
|
I can't remember why I wanted ... and now I really want to try a RoutesIO ... I never got to try Snap. |
Beta Was this translation helpful? Give feedback.
-
|
History lesson, since a lot of old ideas are new again in this thread:
|
Beta Was this translation helpful? Give feedback.
-
|
fwiw, I don't love the typeclass, I'm just intrigued by having the |
Beta Was this translation helpful? Give feedback.
-
|
I'm also 👎 to reviving the typeclass. I would rather have a bespoke data type. A reencoding of 0.4 could do it without a dubious Monoid[Response] or materializing the Option. |
Beta Was this translation helpful? Give feedback.
-
|
This is a bad encoding of Service. I tried to abuse null as sentinel value, but:
But the interface more or less works? |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to see how it works with |
Beta Was this translation helpful? Give feedback.
-
|
#6769 is not optimized, but encapsulated, and with Resource. It gets us through Monad, MonoidK, and Local. Now that I type that out, I should have gone all the way to Alternative... |
Beta Was this translation helpful? Give feedback.
-
|
I like this – especially because I loathe type aliases. It always seemed like a leaky abstraction to me. Is there even a viable solution for newtypes that works across scala 2/3? It might even make sense to introduce a friendly name for <+> now with the added context? |
Beta Was this translation helpful? Give feedback.
-
There are. For example:
I actually tried a newtype encoding for |
Beta Was this translation helpful? Give feedback.
-
|
I don't know that we need to worry too much about newtypes for this use case. We want to interpret to an efficient function, but it doesn't really matter how much the interpreter itself allocates, because that runs once. Any performance problems in the Kleisli model -- which are enormously overstated -- come from the shifting, not the case class wrapper. |
Beta Was this translation helpful? Give feedback.
-
|
The advantage of the newtype would be that we could easily reuse all the |
Beta Was this translation helpful? Give feedback.
-
|
That's a nice idea. Depends if we land on a specialized algebra or just a transformer with reader at the outer edge. |
Beta Was this translation helpful? Give feedback.
-
There have been several discussions on Gitter and other venues around
HttpRoutes/HttpApp. One argument that keeps coming back when newcomers see http4s is that these types are difficult to understand when you dealias them - mostly everyone using Scala understands functions andOption, but not everyone coming to the language will know whatKleisliandOptionTis.I think this complexity isn't worth the benefit - composing routes with
<+>could be done if it was an operator defined directly on some concrete type, middleware could wrap a function intoKleislito make transformations more easily, and internals supposedly don't rely on this shape either.For that reason, I would like to bring back an idea suggested by other people in the past:
We already have
HttpApp.of/HttpRoutes.ofwhich are really good for avoiding the complexity at definition site, but the moment someone sees a type mismatch (e.g.bindHttpApp(httpRoutes)), they see the monad transformer gang. A change like this would make it possible, while keeping existing functionality (assumingHttpRoutes.applyexists anda => HttpRoutes(a.run)is identity).I would love to see this in 1.0 and I'd be happy to work on this, if we have consensus that it's a good idea.
I'll dig up the recent discussion later, unless someone beats me to it. :)
Beta Was this translation helpful? Give feedback.
All reactions