Explicit support for lists as registry keys

[helins]

Currently, the preferred format for keys in registries are keywords and strings. However, I find it useful to allow composite keys as well. Composite keys can be a bliss in some situations keywords, even namespaced, fall short.

Latest sophisticated example I have is using Malli for describing a type system. It turns out to be very convenient, very neat properties for code generation. In my situation, a same function can have different return types, so imagine this simplified model. This actually works already:

(def reg {'(some-fn :double) :double
          '(some-fn :int) :int})

(m/validate [:schema {:registry reg}
             '(some-fn :int)]
            42)
;; True

Generation works as well. However, support is not total. For instance, malli.core/-reference? throw if a schema is not a string or a keyword. So:

1. Do you think it is a bad idea allowing composite keys as lists? Some reasons I didn't envision?

2. If not, should we limit ourselves to lists? Lists are very recognizable (not often used). Maps work as well, but they are already used a lot in Malli, might maybe clash with something someday.

3. If a solution is accepted, are there other places that we would need to change besides -reference?.

[ikitommi]

Original idea in supporting only strings and keywords was to limit ways one mess things up - If anything could be a reference, one could have a registry where core types are accidentally changed into something else, like: {:int :string}.

supporting maps or vectors would definitely make it clash with normal syntax:

[:schema {:registry {{:closed true} ::a
                     ::a :int
                     ::b :int
                     [:size :int] ::b}}
 [:map {:closed true}
  [:size :int]]]
;; ~> [:map ::a ::b]

Using a list as a key would work at the moment but it would reserve lists for reference lookups. Options:

1. don't support
2. add support for lists as reference types
3. make m/-reference take the options as second argument and add an option to override the behaviour, open but most complex

I don't know any better use for lists, so 2 would be ok, if you still need this. PR welcome.

[helins]

The idea of having a composite key is to be more programmatic when creating schema. The kind of problems I am currently working on might be too abstract compared to common web dev where schemas are written by humans (I guess). Maybe leave the issue open and sleep on it for a while?