Unqualified :as syntax inside map pattern can be problematic

[yuhan0]

Vector and map patterns currently accept the special :as key which binds to the entire structure, however unlike Clojure's destructuring syntax, it is ambiguous when attempting to match with an actual map key named :as

(m/match {:as [1 2 3] :bs [4 5 6] :cs [7 8 9]}
  {:as ?as :bs ?bs}
  [?as ?bs])
;; => [{:as [1 2 3], :bs [4 5 6], :cs [7 8 9]} [4 5 6]]

Also the analogy with map destructuring doesn't completely hold, eg. :keys does not bind to the map keys.

With epsilon's shift towards namespaced operators, would it be appropriate to use a symbol like m/as or m/bind instead? Either in its current position:

(m/match [1 2]
  [?x ?y m/as ?v]
  [?x ?y ?v])
;; => [1 2 [1 2]]

Or as an operator outside the literal pattern:

(m/match {:a 1 :b 2}
  (m/as ?m {:a ?a})
  [?a ?m])
;; => [1 {:a 1 :b 2}]

[jimmyhmiller]

Definitely agree that it should be namespaced. Personally I still like it being a keyword and not a symbol. You can do the operator style with m/and. Though it might still be good to add an explicit as operator as well.

Thanks for the issue.

[noprompt]

@yuhan0 Great example of the problem. We could support the qualified keyword :meander.epsilon/as (thus making ::m/as possible), however, to phase out :as would require a branch to zeta since that'd be a breaking change. zeta is bound to happen eventually, however, I'd probably like us to have few things planned for that before it get started. My question is whether to support the qualified keyword in addition to the unqualified version today.

In addition to the suggestion @jimmyhmiller made, you can also quote :as to have Meander treat it as a literal:

{':as ?as :bs ?bs}

[timothypratley]

I preferred quoting clashing terms than using namespaces!
The minor annoyance when they occur is worth the clean expressive patterns.
m/ everywhere is just a distraction IMO.
In Clojure namespaces are important for good reasons largely around diverse libraries and data models, but meander patterns do not require them as the operators and semantics are well defined in the same way that Clojure core does not need to be namespaced (even though you can refer to it in namespaced form).
Having said that I understand you need to cater to a broad group of users and I am possibly in the minority in wanting to keep them out of my patterns.

It occurs to me that you could offer a way to control if/when unqualified op will be used... I am wary of this approach because of possible fragmentation in how people express patterns, but to follow Clojure where you can (set! *warn-on-reflection* true) you could potentially provide a (set! *m/qualified* true) and allow things like (binding [*m/qualified* true] (something)) or a macro to sugar that as (m/qualifed (.......)).