Welcome! Please see the About page for a little more info on how this works.

0 votes
in Collections by

From a theoretical standpoint, there really isn't a difference between a Map and a 1-arity function

What do you think of having a Function implement the Map interface? Will it be useful? If this was thought and you guys decided not to go with it, why not? Would love to learn the thinking

3 Answers

+1 vote
by
selected by
 
Best answer

There is a lot of utility in making things functions, because that is the main abstraction for "things you invoke". There's a lot less utility in turning functions into maps (data). You can't easily read/print them like data, you can't generally compose them with other data, etc. Additionally, while all maps can be invoked as a lookup function, not all functions can be invoked as maps so it could only apply to a narrow set of functions. So, I'd say it's not useful and I don't see any benefit that would be gained from it.

+1 vote
by

What problem are you trying to solve?

by
Not really trying to solve a problem
I was just going through how symbols and keywords can act as functions that  do a lookup on the 2nd  parameter that  gets  passed to them (a map)

So just wondered a function is sort of a map too so (:key some-fn) should've worked but  that's ok because we can always write it as (some-fn :key)

I think the keyword/symbol as function was just a convenience?
by
but i'll definitely think if it will be helpful in anyway
by
Also, consider that you can say (some-map "a-key") but you can't say ("a-key" some-map) and you can say (some-vector 42) but you can't say (42 some-vector) -- it's not symmetric (and there's no reason for it to be). There are lots of things that can be a key/index on an associative thing that could not be used in the first position as if they were functions.
by
totally makes sense :) Not a language designer, so was just trying to understand the thought process
+1 vote
by

Semantically speaking, some properties of a Map are impossible to project to functions. Maps have count of elements, maps allow enumerating all elements they contain, this is not possible to do with functions.

Another downside I see is unpredictable complexity of get. Currently when calling get on a map, you can expect operation to be reasonbly fast. In case of (get itentity 1000) it holds, in case of (get #(do (Thread/sleep %) %) 1000) it doesn't. I like Clojure's predictable execution times, such as with conj, that is guaranteed to be O(1), while not guaranteeing item will be inserted into an end of a coll.

by
Wow the  first point  @vlaaad makes so much sense. Almost forgot  about that :) Thanks both of you
...