namespaced keys are actually awful
you wanted a record type not an infinite union of a bunch of shit
Conversation
Interesting. In what context? Clojure? I've actually wondering if the lack of namespaced labels has been part of the problem with implementations of extensible records in the past (OCaml, Purescript, Elm, etc), and part of the reason they don't get as much use…
1
2
yeah it's an idea I kicked around some as well. I think it solves a category of inheritance problems I've found rare or at least avoidable in my Clojure work, and I generally fall in the restrictive formalisms help actually camp.
1
1
the particular case I'm subtweeting here is a library for storing configuration as records where the records have a uniformly defined interpretation so the ability to play fast and loose with these structures kinda defeats the purpose of the library.
2
Also because Clojure uses code namespaces for keyword namespaces, I find the ergonomics to frequently be combersome because namespaces must form a DAG and referring other namespaces just to create convenient keyword aliases is risky at best.
1
1
Either you massively increase the verbosity of normal record accesses or you introduce artificial code loading control dependencies. Hardly ideal.
2
2
Replying to
Yeah, I imagine it would also get annoying once you start using namespaced symbols for keyword arguments too. Something I like in theory, but have trouble justifying from an ergonomics perspective.
Replying to
You could hack Clojure to let you create namespace aliases without loading the aliased namespace, but that's just wallpaper over the fact that tying keyword (magical string keys) naming to code locations doesn't seem great.
1