Are there design considerations behind allowing keywords to be functions, but not strings or numbers?

Wed, 08 Sep 2021 20:24:28 +0000

related to a thread on clojureverse: https://clojureverse.org/t/x-x-auto-transducifying-thread-macros/8122/26

,where the author's library provides a transducerized variant of ->> called x>> that recog,nizes transducers and tries to turn the threading expression into an efficient transducer form.

The author then decided to fold in keyword-access semantics for strings and numbers, to enable threaded expressions that equate to get or get-in with less verbosity. Something like

(let [m {1 {"b" [0 1 {:c :res}]}}]
     (x> m 1 "b" 2 :c name)) ;=> "res"

which is akin to the keyword idiom of

(-> m :a :b :c) ;;some-nested-value

Is there any reason why in the general case, eval should not support keyword access semantics for other simple types like numbers and strings (maybe booleans, whatever)?
Aside from being unable to extend IFn to strings and numbers (this would have to be handled with additional type checks dispatching on the first arg instead of focusing on IFn), are there language design arguments against this? I am unable to derive any off the top of my head.

Clojure Q&A - Recent questions tagged language keyword string function

Are there design considerations behind allowing keywords to be functions, but not strings or numbers?