Practically speaking, Java numbers cannot be extended with the IFn
interface to make this possible.
On Mon, Nov 13, 2017 at 9:15 AM, Alex Miller <a...@puredanger.com> wrote:
> 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.
>
--
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.
