https://kotlinlang.org logo
Join Slack
Powered by
<@UDEC96MU7> Is that the Milewski book?
# arrow-contributors
b
@addamsson Is that the Milewski book?
a
yes
i don't think that my brain is wired in a way that i would understand it
SICP was a breeze but for this i'm missing some context which I think is only in the author's brain
b
I've attempted to just read through it and came to the conclusion I actually need to do the exercises
but there seems to be a steep increase in learning curve around page 100
a
which one, SICP or CTFP?
b
CTFP
a
i see
my problem is that it introduces new concepts without explaining them
then uses these concepts as if they were known to the reader
for example it introduces `typeclass`es without explaining what a typeclass is
it introduces things like 
m -> m -> m
without explaining why this is useful
or what currying is
b
Yeah, it does. On the other hand it does not assume much Haskell knowledge. To some extent I wish he would have skipped the C++ examples altogether, although pointing on the equivalence between 
void
and 
Unit
was useful
TBH I haven't found a good reference for higher-order FP. I take a shotgun approach, so I read CTFP, lurk in the Scala Cats ecosystem gitter channels and Arrow channels, read through examples, attempt things as I have time
it's slow going since it's not my day job šŸ˜•
There was a good discussion on exactly what F[A]/F<A> means in the cats gitter channel yesterday, let me see if I can track it down
and the example application in the "Get Starting" guide of http4s is the best example I've seen of algebras polymorphic over effect types composed with programs written in the effect type
i
Hi @addamsson, I am a mere beginner in FP, but this read should help. https://arrow-kt.io/docs/typeclasses/intro/
If not I can also reiterate and explain it in my words
b
I found the most useful interpretation of "typeclass" to be "an extensibility mechanism where an interface can be implemented for a type without modifying the original type definition" - i.e. it is possible to implement a typeclass for any existing type even if the type is hidden away in a library, for instance
i
Hi @Bob Glamm if youā€™re doing the exercise you can make some PRā€™s for your work if you translate them into Arrow: https://github.com/arrow-kt/Category-Theory-for-Programmers.kt Just look for open Issues or missing exercise translations
b
I'm still at the stage where I'm drawing arrows and objects šŸ˜„
šŸ‘ŒšŸ½ 1
a
sorry you misunderstood me
i know what a typeclass is but now because i've read CTFP and understood it from there
but this is a good idea, I'll read through the arrow docs first
@Bob Glamm i'd recommend reading the discussion on GitHub for KEEP-87, it has great insights about what a typeclass is (an extension interface)
b
nod, I've read through parts of it, I will need to take another look
a
hi @Imran/Malic , Iā€™m new to FP and start using Arrow earlier this year. Iā€™ve tried the Arrow typeclass doc a few times but still find it hard to get my head around. My current understanding is that a typeclass is something like a Java Comparator, which can define some extra behavior for a type T. And Iā€™m not quite sure whatā€™s the benefits of defining the methods as extension methods in a typeclass except that it reads better.
May I know whether thinking it as similar things as Javaā€™s Comparator interface makes sense?
b
The most useful benefit of typeclasses is being able to extend existing types with typeclass implementations without modifying the original type
e.g. in Java my type has to "implement Comparator" - if my type is final or in a 3rd-party library I can't actually "implement Comparator" because the type definition cannot be changed
This constraint is eliminated for typeclasses - e.g. if I have a "Comparator" typeclass (usually called "Order") I can implement an instance of that typeclass for any type, regardless of whether I have access to it or not
a
Hi Bob, thanks for your explanation! I think you meant ā€œimplement Comparableā€(different from Compartor) in your example. Based on your explanation, a Java Comparator is actually a typeclass.
i
Hi @Alpha Ho I hope this helps: Essentially, when we step back and think about what a program means. One can think of it as such, a program is composed of functions which imply Actions, and typeclasses which imply a set of behaviors. Now the problem in oop is that it is hard to encode composable behaivors with class hierarchy, whereas with ā€œinterfaces with superpowersā€ aka typeclasses we sure do. The most plain answer I have is: When ever someone talks about typeclasses they imply composable ā€œinterfacesā€ 
with a specific behavior
a
So is it like the parameter(s) taken by different higher order functions, while besides the type constraints (like it must be 
A -> B
), it also has some constraints on semantics( like it implements Monad/Monoid typeclass)?
i
And now coming back to the idea of a program, whenever we have behavior and an action, we can simplify our reasoning exactly on these 2 premises. Whenever someone callā€™s 
map
in Kotlin over <Something which has a behavior>, we immediately can reason over itā€™s action without looking at the implementation. Because we know the set of behaviors and the action becomes universal, but not in a cat theoretical sense - for those reading.
a
While a higher order function abstract some behavior by parameterization, the parameter is constrained only by the type. For example, 
List.map
may abstract the behavior of a loop, the parameter of 
map
is constrained by the 
from
type and 
to
type. If I have a 
List<User>
and I want 
List<Name>
, then the parameter need to be type 
(User) -> Name
While the space of a function that fits 
(User) -> Name
can be extremely large, thereā€™s only a smaller subspace that may fulfill the semantics of a specific typeclass
and that semantics may be enforced by some laws, like Functor laws, etc.
if we take 
listOf("b", "a").sortedWith(Comparator { ā€¦ })
as an example, thereā€™s may be slight difference between 
sortedWith
takes a function and takes a Comparator. As the latter one comes with a stronger semantics
not sure such gibberish makes sense
šŸ˜‚
i
Well your mixing different things. What is your understanding of a Functor?
a
I took Functor in my lines just because thatā€™s the only thing that I can think of has laws
Functor to me is anything that has a 
map
function and also obeys the functor law
But that understanding seems not be very helpful for me with my daily workšŸ˜…
i
Quite write, maybe I can reiterate on your answer. Functor is a type constructor it takes a type and returns one: 
* -> *
, please donā€™t confuse that with HKT.
a
hmmmā€¦. that seems to confuse me more
šŸ˜„
i
map
does not model loops. Loops are to general, you can do a shit tone of things in them: Sideeffects, break the program and much more. The problem is that with so much possibilities you can not really know what happens in a loop. 
map
allows us to safely compute over values under the assumption that the return value of 
f
encapsulates for instance the container
So when we have a 
List<A>
and a 
f: (A) -> B
we know the return is 
List<B>
and there are no sideeffect or else happing in that function
so think of 
Functor#map
as a specific loop, which is pure and only iterates over values in the container
Coming back to typeclasses: The most important thing here is that your dealing with Composition not Inheritance, is that clear?
a
agree on ā€œ`Functor#map` as a specific loopā€
i
Good now what about the composition part?
a
by composition, is it the same as saying that any type can implement a typeclass?
i
I can not really agree on your answer.
try again
a
ā€¦.and any type can implement different typeclass at the same time?
i
classes implement typeclasses, In Arrow their mostly data structures such as List
a
hmmm.. whatā€™s the difference between types and classes?
so is it the case that the typeclass composition means different classes can implement different typeclasses?
i
a
I thought classes and types were used interchangeablyšŸ˜„
i
hell no
a
let me read the doc through
i
But itā€™s fine šŸ™‚ Your getting it
a
hmmm, seems the ā€œclassā€ mentioned in the doc means typeclass, is it correct?
which I think should be different from the ā€œclassā€ in a java/kotlin context
i
you mean class constraints?
b
?? 
* -> *
is an HKT. (It also happens to be a type constructor)
i
Itā€™s only a visual representation. That 
* -> *
can mean different things depending on the context.
a
sorry, I meant class in Kotlin
Itā€™s a bit late for me. Let me go through what we discussed again tomorrow to see whether i can get a better understanding. Thanks both of your time! @Imran/Malic @Bob Glamm
i
@Alpha Ho you can read this tomorrow https://www.parsonsmatt.org/2017/01/07/how_do_type_classes_differ_from_interfaces.html remember this sentence when you read this article: 
What differentiates FP from OOP is that typeclasses are meant to be implemented outside of their types, instead of by the types.
Thank you too for asking šŸ™‚
šŸ‘Œ 1
b
++ nice reference, I hadn't read that before
2 Views
Open in Slack
PreviousNext
Powered by