dave08
02/16/2023, 12:08 PM?.
and ?:
be overridable operators for a non-null type... then it could avoid all the `bind()`s and `flatMap`s and hacks that Arrow is doing... did someone ever propose such a thing? (or maybe some similar operator if people might find it too confusing and think that they're dealing with nullables.)simon.vergauwen
02/16/2023, 12:21 PMbind()
and you can already write code that avoids bind
in 99% of the cases.
At I gave a talk about doing this for Resource
, and you can do the same for Either<E, A>
when relying on Raise<E>
(in 1.2.x or in 1.x.x EffectScope
). You can achieve the same as Either.Left(e).bind()
be calling the raise(e)
DSL. The Raise
DSL exposes functions to do things like error handling over E
and Throwable
etc.
So there is not really a need to be-able to override ?
, I think that might make things more confusing. Raise
, ResourceScope
, and many other DSLs you can design (and we have in Arrow) can avoid this problem.Either
and bind
in there code.dave08
02/16/2023, 12:28 PMRaise
in the ktor example video, but I for now, I see a code base full of functions with context(...)
before them, which in this case is just a bit of boilerplate compared to something like an official operator overload...simon.vergauwen
02/16/2023, 12:30 PMit's just a technical detail that you need it to compose the either's togetherNot really, since they're part of your domain. Even with
?
or ?:
you would need some way of tracking the type in the type system. Similar to how nullable types are part of the type system Int
vs Int?
.
How would you represent that ?
is being used for MyError
? That is exactly what Raise<MyError>
does in the context
(or as extension). Other languages offer deeper integration, or different syntax for context
. I.e. Raise[MyError] ?=> Int
in Scala.Raise[MyError] % Int
using infix typesdave08
02/16/2023, 12:33 PMEither<Error, Success>
in the return type as much as the clutter of nested flatmaps... the context receivers of Raise
work at getting rid of the return type as well as the flatmaps...@Throws
FP style... I'm sure others would love that and it wouldn't bother them... I'm just wondering if for the some that don't mind/want explicitness in the returning type there could be something "in the middle" not too cluttery, not too implicit.?.
would be that you'd still have to get the result from the previous computation: getUsers(...)?.let { getAddress(it) }
so it doesn't really save anything apart from looking a bit more like a standard "I didn't get something valid from the previous computation (null = Left...)"