https://kotlinlang.org logo
Join Slack
Powered by
``` fun <K, V, R> Map<out K, V>.map( ...
# arrow
a
Copy code
fun <K, V, R> Map<out K, V>.map(
    transform: (Entry<K, V>) -> R
): List<R>
Why does 
map
for 
Map
in stdlib return 
List
instead of 
Map
?
i
You would use MapK’s 
map
to map over every 
V
a
I only wanted to have a discussion, and this channel seems to be active for functional discussion.
r
Map can’t form a Functor because it can’t guarantee order so a map function on a map returns a List which guarantees order. The way I see it. Not sure that is the reason why the stdlib does it
a
Do functors even have to honor the ordering?
i
Yes, otherwise 
map
doesn’t make sense
One way to see that is when you look at Functor Laws, for instance this one:
Copy code
fmap (f . g) = fmap f . fmap g
Functor’s need to obey the order in order for this to work. It is implicit for sure.
a
I don't know about that but there's a Functor instance for Unorderd Map here: https://hackage.haskell.org/package/strict-data-0.2.0.2/docs/Data-Map-Unordered.html
s
I am not 100% sure about the ordered bit but in the Kotlin std everything returns 
List
. Everything that is an 
Iterable<A>
returns 
List
on 
map
.
So maybe it’s just to be consistent.
a
I see
s
setOf(1, 2).map { it + 1 }
calls 
fun <T, R> Iterable<T>.map(transform: (T) -> R): List<R>
Which means that if you implement 
Iterable
you get map for free but it turns your structure into a `List`…
t
map can't change anything that is part of the functor type. just the "inner type".
The structure must remain the same.
Which means that if you implement 
Iterable
you get map for free but it turns your structure into a `List`…
Which means that 
map
of Iterable is not the same 
map
of the 
functor
it basically breaks this law: 
map id = id
for any Functor that is not a list
But this one 
map (f . g) = map f . map g
should still hold.
@Raul Estrela Functor laws says nothing about order. If order is not a property of the 
Map
type then it shouldn't matter for its 
=
operation as well.
👍 1
And if order doesn't matter for equality, tell me, why can't a 
Map
form a functor?
What we have to understand is what makes 2 "objects" equal. In the case of the 
Map
I would say that Map A and Map B are equal if for every (x, y) in A, it is also in B, and for every (x', y') in B, it is also in A. It's specific of the general Set equality.
so, from what I know, having the 
map
of 
Map
returning a 
List
is simply wrong.
and there is a valid 
map
for 
Map
Yes, otherwise 
map
doesn’t make sense
This statement is wrong. 
map
respects order for list, because that is a property of a list, if 2 list do not have the same ordering, they are not the same list. But that is not true for Sets, ordering is not a property of the set, order does not matter for the set, so 
map
doesn't need to respect it. 
map
just has to respect 2 laws: 
map id = id
map (f . g )  = map f . map g
(in fact, because of free theorems, making sure the 1st law holds is enough)
i
t
it could not guarantee for example that mapping over the identity returns the same value if each time you iterate you get a different order.
Why? Why would order of iteration would matter? Can you give an example on how applying 
id
with different order would break the law?
@Imran/Malic
i
The idea behind 
Functor's#map
is that it leaves the structure from 
F
unmodified
Thus all data types, where order is not a requirement can not form lawful functors
t
if order is not a requirement, order is not part of the structure, which means the structure is not modified.
i
Well, that’s one way to see it. 🙂
t
IT is the definition of Set
It is what makes a set equal
it is what the laws are all about
it is math
How the machine intrepets it, should be irrelevant to the math of it.
s
We provide 
Functor
instances for `Map`…
❤️ 1
➕ 2
t
It {1,2,3} is equal to {3,1,2}, event if we show it in a different order.
s
And those instances are checked with 
FunctorLaws
property based testing.
OrderedMap
has a separate instance that relies on 
Order
typeclass to guarantee order.
Kotlin std’s is the oddball here since it provides an extension on 
Iterable
since the language doesn’t understand higher kind polymorphism. With KEEP-87 that could be rectified in the std.
👍 1
t
Thanks Simon!
s
You’re very welcome 👍
r
thanks for clarifying Simon, I was wrong here and got confused with the set instances
👍 2
3 Views
Open in Slack
PreviousNext
Powered by