~ returning map/set does not work the same as map/set pattern

[ribelo]

(let [m1 {:a 1}
      m2 {:a 1 :b 2}
      p {:a 1}]
    [(match m1
            ~p :ok
            _ :fail)
     (match m2
            ~p :ok
            _ :fail)
     (match m2
            {:a 1} :ok
            _ :fail)])

=> [:ok :fail :ok]

[timothypratley]

I believe there is a restriction that the pattern to match with must be completely specified at compile time.

You can enforce this by using an eval macro:

(defmacro k [p]
  `(m.strategy/match ~(eval p) :ok _ :fail))

The "strategy" version of match returns a function, so k here returns a function that takes an input to match against a pattern that was expanded at compile time.

(def p {:a 1})
=> #'justice.core/p
(macroexpand-1 '(k p))
=> (meander.strategy.gamma/match {:a 1} :ok justice.core/_ :fail)
(k p)
=> #object[justice.core$eval259133$fn__259134 0x68df5e75 "justice.core$eval259133$fn__259134@68df5e75"]
(def q (k p))
=> #'justice.core/q
(q {:a 1})
=> :ok
(q {:a 1 :b 2})
=> :ok
(q p)
=> :ok
(q {})
=> #meander.gamma/fail[]

[noprompt]

@ribelo ~expr gets compiled to an equality check on the evaluated value of expr which is why the second case fails. Here's an example that may help make this a bit more clear.

(let [m1 {:a 1}
      m2 {:a 1 :b 2}
      p (fn [] {:a 1})]
  [(match m1 ~(p) :ok _ :fail)
   (match m2 ~(p) :ok _ :fail)
   (match m2 {:a 1} :ok _ :fail)])
;; =>
[:ok :fail :ok]

I am open to compiling a more intelligent check pending some thought on the implications.

[timothypratley]

@noprompt What does "more intelligent check" mean?

It appears to me that equality is the only sensible option, and is a feature... being able to match a literal map instead of a map pattern. So FWIW I don't think this behavior should be changed.

Assuming you do want to preserve this behavior there are several places in the docs where it would be useful to call out how ~ behaves, but if the semantics aren't fully locked in yet then that would be counter-productive.

Stated another way; what is required here to close this issue?

[noprompt]

I was thinking we could switch to interpretation where an internal matching function which does not bind for this purpose could be used.

~{:a 1, :b 2}
;; Compiles to
(m.match.runtime/matches? target-value {:a 1, :b 2})

But its unclear to me whether or not that is a good semantic or not.

[timothypratley]

Another question that comes to mind... is there a way to insert pattern literals into a pattern? I can't think of one besides the macro approach described above. defsyntax allows us to insert a predefined pattern, but not one that is an argument. One idea is to offer a wrapping macro:

(m/with-context [p {:a 2}]
   ...)

FWIW I'm wary of the runtime binding approach.

[timothypratley]

Bah m/with-context idea doesn't really help as you'd still be limited to compile-time usage still so not useful. Exposing runtime matching should IMO be an explicit, opt-in thing.
Like (m/pred #(runtime/matches? % p) ?x) or a conveinience wrapper (m/runtime p).
Is that possible? I also couldn't find meander.match.runtime.epsilon/matches? <-- maybe i'm looking in the wrong ns?

[noprompt]

@timothypratley I was just throwing out an idea. There's no such function at the moment.

[timothypratley]

oh right! :)

[noprompt]

I'm open to supporting configuration of ~ semantics (currently through meta).

There are a number of possibilities but I think something like

^{::m/equality (var my-custom-equality)}
(m/<macro> ,,,)

or

^{::m/equality my-custom-equality}
(m/<macro> ,,,)