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
That said, I definitely like the idea of having field and method accesses be namespaced in an OO system. Would really clear up eg. method name overloading. That's an idea I poked at with one of my toy VMs.
1
1
Replying to
Yeah, I'm pursuing a dependently typed, 1ML-inspired approach. Was thinking the idea of 'field/variant labels' could be boiled down to a single gensym kind of thing. You could pass labels around and import, or access via projection. Could be overly tiresome in practice though.
Replying to
neat! I was poking at a JVM clone where method names retained their full interface or type name in the implementing class so you could get somewhat meaningful multiple inheritance and very ready name overloading between interfaces.
1