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 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
and not the main mental model to think about this
as shown by the thought experiment above
the main mental model is referential transparency, and the sort of reasoning it allows you to do
once (if) you appreciate that sort of reasoning, which is often not taught well (or at all), you also tend to see the point of IO in the first place
if you don't, then it's easy to think of IO as only adding ceremony
Andrey
@404-
by this logic, would it be wrong to think of IO[A] as a function () => Either[Throwable, A]?
because i can't get over seeing it that way
Fabio Labella
@SystemFw
well, for starter your IO is sync only
whereas cats IO can do asynchrony and concurrency
second, the point of FP is starting to think in terms of semantics, and not implementations
algebraic thinking
this is something I really care about, because that's the biggest benefit
when I teach, it's my main focus
Andrey
@404-
reasoning in terms of values, yes?
Fabio Labella
@SystemFw
however, it's generally not taught, and it's not easy to make the switch
more generally, reasoning in terms of the denotation of something (what meaning do we assign to its operations), vs its implementation
it's a very broad perspective, that changes the way you look at things from the nature of types, to IO, to final tagless, and so on
I can give you a small example
if you wish
Andrey
@404-
sure
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