Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 01 2021 10:11
    @SystemFw banned @Hudsone_gitlab
  • Jan 31 2019 04:19
    404- forked
    404-/fs2
  • Jan 31 2019 03:01
    SethTisue commented #1232
  • Jan 30 2019 17:22
  • Jan 30 2019 13:45
  • Jan 30 2019 10:48
    pchlupacek commented #1406
  • Jan 30 2019 10:47
    pchlupacek commented #1406
  • Jan 30 2019 10:39
    pchlupacek commented #1407
  • Jan 30 2019 09:58
    lJoublanc commented #870
  • Jan 30 2019 09:42
    vladimir-popov commented #1407
  • Jan 30 2019 08:10
    vladimir-popov closed #1407
  • Jan 30 2019 08:10
    vladimir-popov commented #1407
  • Jan 29 2019 19:20
    SystemFw commented #1407
  • Jan 29 2019 19:20
    SystemFw commented #1407
  • Jan 29 2019 18:57
    SystemFw commented #1406
  • Jan 29 2019 17:47
    pchlupacek commented #1406
  • Jan 29 2019 17:42
    pchlupacek commented #1406
  • Jan 29 2019 17:39
    pchlupacek commented #1407
  • Jan 29 2019 17:39
    vladimir-popov edited #1407
  • Jan 29 2019 17:38
    vladimir-popov commented #1406
Fabio Labella
@SystemFw
the context for this example is about ApplicativeError/MonadError
are you vaguely familiar with them?
raiseError, handleErrorWith, attempt, and so on
Andrey
@404-
yep. that's why i was saying () => Either[Throwable, A] above
Fabio Labella
@SystemFw
wait a sec
so, in that context
how would you define what an error is?
Andrey
@404-
something out of ordinary but still expected
Fabio Labella
@SystemFw
that's not a programming definition
it's a human definition
Andrey
@404-
expected == coded-for
Fabio Labella
@SystemFw
I would define it this way
an error is something that makes a flatMap/mapN short-circuit
or more precisely, an e such that raiseError(e).flatMap(f) == raiseError(e)
Andrey
@404-
makes sense. but it's something that must be kept in mind and can't really be set aside
Fabio Labella
@SystemFw
you can add to this definition ofc, for example by saying that it's something that be handled by an handleError
or
raiseError(e).handleErrorWith(_ => fa) == fa
right, but the point of the example is not really about errors
do you see a concrete type, or even a concrete scenario, in my definition of error?
not really
I'm just defining it in terms of some operations, and their relationship with each other
this is an example of algebraic design
Andrey
@404-
sure, but this is where i kind of get lost. IO is duplicitous, it's hiding the fact that errors can and do occur, no?
Fabio Labella
@SystemFw
i'm trying to get to the algebra of errors, the set of operations and laws that govern errors

IO is duplicitous, it's hiding the fact that errors can and do occur, no?

That's an entirely orthogonal discussion

btw no, IO it's not hiding anything
because IO is MonadError[IO, Throwable]
which tells you that part of the algebra of IO is being able to raise and catch (in the sense I've given above) arbitrary errors
but the point I'm trying to make is not about IO, or even about errors
it's about mindset
when talking about errors, I'm not talking about Either or throw/catch
I'm talking in abstract, algebraic terms
and this approach has several benefits
Andrey
@404-
i think i understand that
Fabio Labella
@SystemFw
it takes quite a lot to internalise this btw, and many examples. It shouldn't' be seen as something trivial that you just "get"
using this approach pervasively is a huge part of what makes FP nice
Andrey
@404-
what i've been struggling with is how this facilitates reasoning about asynchrony and errors
Fabio Labella
@SystemFw
when you say "I think of IO as () => Either[Throwable, A]", you are not thinking in these terms
you are thinking in terms of implementation
and btw, that formulation above is synchronously only, so it happens to be an incorrect model for the implementation as well
well, for one thing you have a unified model for what it means to be an error (continuing with the example)
works for IO, Stream, Either, or doobie's ConnectionIO
it gets to the point that all I need to tell you is that something is MonadError[F, E] and you already know how to do a large class of things with it
which is entirely unlike the experience in OO
moreover, some of these operations can be written once, and work for all these things
for example, doing an action on an error and then rethrowing it
which is onError on monad error
as opposed to having to write lots of similar but not quite the same code all over the place
errors is just one example btw