Regarding the title, this is incorrect. Map keys are not functions; keywords are functions that take an associative data structure and will look themselves up in it. So, the premise here is not even correct to start.
Usually we prefer to work by starting from a problem and consider alternatives, but as you state below, you don't have a problem in mind. On Monday, November 13, 2017 at 3:49:41 AM UTC-6, Stephen Feyrer wrote: > > Hi there, > > This is possibly a silly question (and may have been asked before but I > couldn't find earlier examples) so here it goes. > > We start with a form which we're all familiar with: > > user=> (:this {:this "is" :the "same"}) > "is" > > > Then it's not a stretch to go to: > > user=> (def the 1) > #'user/the > user=> (nth [1 "is" the :same] 1) > > "is" > > > Here's where it gets tricky as we enter the land of make believe and > what-if? > > I suggest a special form where vector elements could be treated like > functions in a manner similar to maps keys. As this is purely > hypothetical there might be better ways of representing this: > > Get the nth element of the vector > > user=> (3 [1 "is" the :same]) > :same > > > Note that you can do something similar now with: ([1 "is" the :same] 3) Whereas in the situation with maps, keywords (a specific common key type) are functions, here you are implying that anything could implicitly be invokable as a lookup function on an associative data structure. This doesn't make a lot of sense to me and would undoubtedly have performance effects. Maybe there is some case like `(map 1 [[:a 0] [:b 1] [:c 2]])` where this would make sense. But this doesn't make sense for all indexed data structures, just those indexed by longs. Layering invocability on longs would require special handling in the compiler (Keywords are a type that embeds this by implementing IFn naturally, so it's not a special case). > Get the nth element of the vector > > user=> (2 [1 "is" the :same]) > 1 > > > Get the nthiness of an element in the vector > > user=> (::same [1 "is" the :same]) > 3 > > This is something completely different - a linear search for a match. Clojure has considered and rejected making linear searching easier multiple times. It's almost always a sign that you are using the wrong data structure in the first place and should be using a hashed data structure instead. There is no chance we would do something like this. > > Get the nthiness of an element in the vector > > user=> (:the [1 "is" the :same]) > 2 > > > Get the nthiness of an element in the vector > > user=> (:1 [1 "is" the :same]) > (0 2) > > I don't even understand what is intended here. > Taking things further into the realms of really you should have stopped > there! > > Get the these element of the vector > > user=> ((1 3) [1 "is" the :same]) > ("is" :same) > > > Just for fun I tried: > > user=> ((:this :the) {:this "is" :the "same"}) > > > > > NullPointerException user/eval786 (NO_SOURCE_FILE:1) > > > > I may be barking up the wrong tree or possibly just barking... I hope > what I'm asking makes some sort of sense. > Not particularly. > By way of apology to the reader, when I began writing this question it was > ill thought out and seemed a lot simpler. As a disclaimer, I can't think > of direct examples how this would improve readability or such or even > necessarily be useful. > Seems like that should have been a sign. :) > Though, that being said, I do believe that there people who'd make good > use of such a feature, though I don't know who they are either but I'm > hoping you're reading this ;) > > My parting shot, I have a guess as to why things are the way they are but > that is completely in substantiated and lacks in even the most basic > rationality as I also guess as to why my guess might not be true... :( > > > -- > Warning! If you question everything the answer you'll get is "EVERYTHING!" > > Stephen. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.