Clojure Q&A - Recent activity in core.match

Commented: :as and & interaction issue

Thu, 04 Apr 2024 16:22:03 +0000

Can confirm the issue still exists in 1.11.1. Also, glchapman's workaround handles it, but I would never have guessed that solution if I hadn't found this ticket.

Answered: Allow `core.match` patterns to contain fully qualified class names

Tue, 17 Jan 2023 17:10:37 +0000

Keep in mind that class symbols evaluate to class instances, which are not constants and should not be in expanded code. So some special care would need to be taken here to expand to something that can be matched appropriately at runtime. I think that's probably possible, but this is maybe a bit trickier than it appears.

Retagged: core.match: syntax error during macro expansion when string key contains a slash character

Wed, 06 Apr 2022 14:51:53 +0000

When passed a map with a string key containing a slash character, clojure.core.match/match errors during macro expansion.

This happens in both Clojure and Clojurescript.

Example:

$ clj -Sdeps '{:deps {org.clojure/core.match {:mvn/version "1.0.0"}}}'

Clojure 1.10.3
user=> (require '[clojure.core.match :as match])
nil

user=> (match/match {} {"a/b" x} x)
Syntax error macroexpanding clojure.core/let at (REPL:1:1).
ocr-1539_a/b__1543 - failed: simple-symbol? at: [:bindings :form :local-symbol] spec: :clojure.core.specs.alpha/local-name

user=> (match/match {"a/b" 0} {"a/b" x} x)
Syntax error macroexpanding clojure.core/let at (REPL:1:1).
ocr-1545_a/b__1549 - failed: simple-symbol? at: [:bindings :form :local-symbol] spec: :clojure.core.specs.alpha/local-name

Expected behavior: it should be possible to match on all strings, even if they contain special characters.

Answered: Bug when matching on a vector with a map clause that uses `:only`

Fri, 19 Nov 2021 20:23:40 +0000

Logged as https://clojure.atlassian.net/browse/MATCH-128

Answer selected: How do I contribute to the README for core.match?

Fri, 19 Feb 2021 06:19:32 +0000

You opened a PR and the PR template you edited has instructions that the project does not take PRs and links to how to contribute (in particular a link to https://clojure.org/community/contributing).

The information there (https://clojure.org/community/contributing#_reporting_problems_and_requesting_enhancements) will direct you first here for filing problems (create in category Contrib libs / core.match) and to contribute patches (https://clojure.org/community/contributing#_development) directs you further to https://clojure.org/dev/dev.

The process involves:

signing the CA (which you've done)
filing a support request to get a jira account (but you already have one)

The JIRA project as linked from the core.match readme is https://dev.clojure.org/jira/browse/MATCH (which is actually out of date but redirects to the current JIRA at https://clojure.atlassian.net/projects/MATCH and is up). I'll fix those links.

Can core.match LiteralPattern emit more specialized code?

Tue, 01 Dec 2020 07:29:48 +0000

Hello,
Looking at the code emitted by core.match, I see that literals are always compared using =.
While it works, wouldn't it be faster to specialize equality for different literals, such as:

 (number? l) `(and (number? ~ocr) (== ~l ~ocr))
 (keyword? l) `(identical? ~l ~ocr)
 (nil? l) `(nil? ~ocr)
 (true? l) `(true? ~ocr)
 (false? l) `(false? ~ocr)
 (string? l) `(.equals ~l ~ocr)

(snippet added to LiteralPattern cond.

Crude benchmarks show it's faster than = and all the tests pass, too.

Think this warrants a patch?

Answered: AppPattern with single wildcard throws exception