Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Paul Snively
@paul-snively
Also, avoiding monads is helpful. Then you can't use for.
Fabio Labella
@SystemFw
forget about Option being a datatype made by Some and None, and don't use pattern matching
Vinayak Pathak
@vinayakpathak
you think using pattern matching distracts you from thinking in terms of compositionality as well?
Fabio Labella
@SystemFw
typing a complete example, hold on
Vinayak Pathak
@vinayakpathak
okay!
Christopher Davenport
@ChristopherDavenport
Yeah, it can make you think of Some/None rather than fold whereas in FP its much easier to see them as Option everywhere.
Drew Boardman
@drewboardman
is there any future plan to enforce typeclass coherence in scala?
like in scala 3 or something?
Fabio Labella
@SystemFw

Option[A] is a program. There are two ways of constructing primitive programs in the " Optional language". One is with pure[A](a: A): Option[A], the other is with empty[A]: Option[A]. Then you have ways of composing these Optional programs. map transforms the result of an Option[A] into an Option[B], assuming you can encode this transformation as A => B. But there is an interaction with empty! empty.map(f) = empty. This gives us semantics: optional programs can express short-circuiting. You can have more powerful ways of composing optional programs, for example by building programs that depend on the result of the previous program: Option[A] => (A => Option[B]) => Option[B] , which is flatMap. Flatmap also shorcircuits on empty programs. Another way you can compose optional programs is by choice, by taking a different path when you find an empty program, this is orElse. Finally, when you are done composing, you need to run this program, which is A => Option[A] => A, i.e. getOrElse.

This exemplifies completely algebraic thinking: I could implement optional programs with the ADT you know as Option[A], or with Either[Unit, A], or with a function (Option.fold), but the way you write and reason about these, in the mindset I just laid out, is unchanged.
@vinayakpathak

Vinayak Pathak
@vinayakpathak
yeah, that makes sense

or with a function (Option.fold)

what do you mean by this?

Fabio Labella
@SystemFw
that you can literally represent Option with a function of a certain shape
(this idea is called Church encoding, or more appropriately in a typed setting, Boehm-Berarducci encoding)
the shape is the same shape you see in Option.fold
you can literally that Option is Option.fold
if you use operational thinking (Option is a an ADT with two cases), you now need to revisit your whole mental model. If you use algebraic thinking like above, it's an implementation detail
the point is that for things like Option, the implementation is easy enough that operational thinking can be helpful. But this doesn't scale to more complicated abstractions like the real cats.effect.IO or fs2.Stream
algebraic thinking does
and you get the power to be able to reason about things whose internals you don't understand
(in practice, there will ofc be corner cases where implementation concerns leak out, but the default mindset should be algebraic)
Dermot Haughey
@hderms
@SystemFw this is another gitter braindump that would be good as a blog post btw
Fabio Labella
@SystemFw
saved in my writings for now
https://systemfw.org/writings (this one is not there yet)
a fuller blog post or a talk would be nice, but unlikely to happen this month
Vinayak Pathak
@vinayakpathak
yeah, we (people who hangout in this channel) should get together and thank @SystemFw in some way at some point... :) there have been quite a few times that I was confused about something and then @SystemFw entered the scene and pretty much answered all my questions with an amazing level of clarity and I'm sure this has happened with many others as well...

the point is that for things like Option, the implementation is easy enough that operational thinking can be helpful. But this doesn't scale to more complicated abstractions like the real cats.effect.IO or fs2.Stream

so algebraic thinking is where we think of things like IO as programs and how we can compose them I guess? so in that sense algebraic thinking for IOis pretty much the same as algebraic thinking for Option?

Fabio Labella
@SystemFw
yes
thinking of a type in terms of the operations it supports and the semantics of those, rather than how it's implemented internally
Rob Norris
@tpolecat
In the specific sense that Option and IO are both monads you can think about them in exactly the same way.
Vinayak Pathak
@vinayakpathak
umm, that doesn't sound very different from what we do in OOP...
Fabio Labella
@SystemFw
in OOP you don't have programs
you don't have values generally
so all these forms of composition don't really work
Vinayak Pathak
@vinayakpathak
i see
Fabio Labella
@SystemFw
Thing.mutate is not a program, is something that has just happened :)
but yeah, in short, think about composing programs into bigger programs
Vinayak Pathak
@vinayakpathak
ok so thinking about programs is what distinguishes FP from OOP then I guess? OOP also gives you the property that once you have defined an abstract class, you can reason about all its instances without looking at the specific details of the instance. In the same way that once you have defined a monad, you can reason about all monads without thinking about their specific details
Fabio Labella
@SystemFw
I wouldn't go this way
and note that in my example I haven't mentioned Monad once
Vinayak Pathak
@vinayakpathak
umm okay
Fabio Labella
@SystemFw
that's a step further: once you think as IOs as programs, and Option as program, you notice that some of the ways they compose are the same, and abstract that into Monad
Vinayak Pathak
@vinayakpathak
i see i see
Fabio Labella
@SystemFw
my point is merely to start thinking about operations and how they interact with each other, i.e. the algebra of a datatype
*there is also another conversation as to why using typeclasses works better than interfaces for this kind of thing, but let's not introduce too many things at once
Vinayak Pathak
@vinayakpathak
probably something to do with "the expression problem" or something
Fabio Labella
@SystemFw
not really :) (although that's another advantage of typeclasses)
Vinayak Pathak
@vinayakpathak
okay i don't exactly understand the expression problem anyway :)
Fabio Labella
@SystemFw
that's fine, it's actually rare that you need it in its full form
Vinayak Pathak
@vinayakpathak
anyway, things have gotten too abstract now, and I have to go home... I should probably buckle down and read TAPL at some point
thanks for answering all my questions for now... will mull over it on my walk home