Clojure Q&A - Recent questions in Multimethods

fn? and multimethods

Mon, 07 Oct 2024 21:25:33 +0000

The docstring for clojure.core/fn? says "Returns true if x implements Fn, i.e. is an object created via fn.", defined in this commit from 2008.

Multimethods semantically act as functions. They're not collections (maps), they're not pieces of data that work like functions for ease (keywords), they're procedures with behavior and input and output. Protocol methods semantically act like functions as well. However, multimethods don't respond to fn? because they don't implement clojure.lang.Fn, they implement clojure.lang.AFn, whereas protocol methods do respond to fn? because they are created with fn* in the defprotocol macro.

This has led to confusion in my code where I have a sequence of function-like objects and in certain cases I want to select only the "semantically function" objects. It has forced me to write fn+? which is implemented as (or (fn? x) (instance? clojure.lang.MultiFn x)). Now, having written it, it works fine and my immediate problem is solved. However, I think this points to an underlying semantic mismatch between multimethods and their implementation.

It would benefit me and others to have this mismatch cleaned up.

Memory leak using the default method of a multimethod

Wed, 28 Apr 2021 08:02:47 +0000

An easy way to reproduce:

Clojure 1.10.2
user=> (defmulti f identity)
#'user/f
user=> (defmethod f :default [x] nil)
#object[clojure.lang.MultiFn 0x4bb8855f "clojure.lang.MultiFn@4bb8855f"]
user=> (dotimes [_ 100000] (f (byte-array 1000000)))

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main"

If you adjust the numbers in such a way so that there's no OOM error, you'll see a persistent leak.

The culprit seems to be MultiFn.findAndCacheBestMethod caching every single value that was matched with the default method.

Self-Like Pattern Using Multi-Methods

Sat, 10 Apr 2021 02:25:08 +0000

Hello,

I’ve reading about the Self language, and got experimenting with multi-methods to mimick Self-style messages. I was curious what folks think about this pattern:

(ns self)

(def path "./hello.txt")

(defn inst [msg]
(if (map? msg) (keys msg) msg)
)

(defmulti hello inst)

(defmethod hello [:save] [msg]
(spit path (msg :save))
)

(defmethod hello :load [msg]
(slurp path)
)

(defn do-run [h]
(h {:save "world"})
(println (h :load))
)

(defn run [opts]
(do-run hello)
)

Do you find this pattern interesting, useful? The example doesn’t show it, but there could be messages with multiple keywords.

Thanks,
- Quenio

Please add dispatch-fn to clojure.core

Sat, 27 Feb 2021 13:49:52 +0000

CLJS has:

cljs.user=> (source dispatch-fn)
(defn dispatch-fn
  "Given a multimethod, return it's dispatch-fn."
  [multifn] (-dispatch-fn multifn))

Can we have this core fn on the JVM as well?

Best way to test for an integer (including java.lang.Integer) in a multimethod dispatch?

Mon, 28 Dec 2020 01:20:38 +0000

It seems (?) like Clojure makes all integers instances of java.lang.Long. I recently found a library I use (which wraps a Java lib) was returning java.lang.Integer instead. This broke a multimethod I have which was dispatching on class.

My solution was to simply make a new defmethod to handle java.lang.Integer. It's exactly like the defmethod for handling java.lang.Long.

Is there a more elegant way to do this? Can a defmethod be made to handle a set of dispatch values? There is a common ancestor class for Integer and Long, java.lang.Number, but I don't want to use that because it will catch floats, which should fall through.

I suppose I could rewrite the dispatch to test if the class of input is Integer or Long and just dispatch those as :int and then dispatch java.lang.String as :string, although that actually may end up being more code :)

Current form is along these lines:

 (defmulti int-or-nil class)

(defmethod int-or-nil java.lang.Long
  [integer]
  (identity integer))

(defmethod int-or-nil java.lang.Integer
  [integer]
  (identity integer))

(defmethod int-or-nil java.lang.String
  [maybe-int-string]
  (try (Integer/parseInt maybe-int-string)
       (catch java.lang.NumberFormatException e)))

(defmethod int-or-nil :default
  [not-int])

Multimethods resolutions when they have the same dispatch value

Wed, 02 Dec 2020 10:08:44 +0000

When two multimethods have the same dispatch value, what is the method of resolution?

In order to answer this questions, I experimented by creating four files (core.cljs, a.clj, b.clj, interface.clj [where `defmulti` is defined]), implemented some methods in a and b namespace with the same dispatch value.

Finally in core namespace, I required a and b, and observed the resolution was given by the order of the import of the namespace.

However, in a bigger project, the order did not have an impact: I was overriding a multimethod in a library, and I suspect the resolution was made with respect to the folder in the classpath.

Can anyone confirm or infirm my hypothesis?

Best regards,
David

Implementing a type or record to support defmethod in CLJ

Fri, 17 Jan 2020 18:37:33 +0000

Thanks to IMultiFn in CLJS types and records can be easily extended to behave as multimethods. For example:

`(defrecord MyMulti
[add-method remove-method dispatch-fn method-table]
IMultiFn
(-add-method [_ dispatch-val f]

(add-method dispatch-val f))

(-remove-method [_ dispatch-val]

(remove-method dispatch-val))

(-methods [_] @method-table))

(def my-multi (->MyMulti ...))

(defmethod my-multi :foo
[x]
...)
`

In Clojure however this isn't as easy because multimethods are not implemented using protocols. IS there ANY way to make a record or type to work with defmethod in CLJ?

Thanks!

behavior of deftests after adding assert-expr methods

Mon, 23 Sep 2019 22:32:29 +0000

The following behavior surprised me
1. define a test that calls (is (= on one item
2. override the multimethod clojure.test/assert-expr to define custom testing for = such that it should error if only one item is present
3. run your test and the multimethod is not invoked since it does not error
4. redefine the test
5. the new multimethod is now invoked.

I'm sure there's a smaller repro but this is the real world use case that came up. CIDER changes this reporting in its middleware but the middleware is dynamically loaded after startup only when needed. Thus this behavior only occurs after using CIDER's testing features and if you redefine your tests.

I'm wondering if this is behaving as expected since deftest stuffs the test in meta or if this is an actual bug.

(require '[clojure.test :refer [deftest is assert-expr]])
(deftest foo (is (= (println 1))))

(foo) ;; no error

(defn =-body
  [msg expected more]
  (if (seq more)
    `(let [more# (list ~@more)
           expected# ~expected
           result# (apply = expected# more#)]
       (->> (if result#
              {:type :pass}
              {:type :fail
               :diffs (->> (remove #(= expected# %) more#)
                           (map #(vector % (data/diff expected# %))))})
            (merge {:message ~msg
                    :expected expected#
                    :actual more#})
            test/do-report)
       result#)
    `(throw (Exception. "= expects more than one argument"))))

(defmethod assert-expr '= [msg [_ expected & more]]
  (=-body msg expected more))

(foo) ;; no error
(deftest foo (is (= (println 1))))
(foo) ;; error

Supporting `add-method` on multi fns to install a function instead of a function tail

Fri, 24 May 2019 05:02:31 +0000

Whenever methods on a multifn need to be installed within a closure (usually to support lifecycle management) using defmethod can be a bit cumbersome and forces having all
method bodies within the closure.

Two cases strike me as most relevant:

If you need a method to capture bindings, it would involve creating a bound-fn and calling that from the defmethod.

With dependency injection framework, you most likely method installation when dependencies are available, making calling defmethod cumbersome.

I attached an example in foo.clj to try to make things clearer and a naive patch.

After discussing things on #clojure-dev with @alexmiller, it seems it would be feasible to add an add-method function and to have defmethod use that.

MultiFn.prefers() ignores the multimethod's internal hierarchy

Sat, 09 Sep 2017 21:26:13 +0000

See https://groups.google.com/forum/#!topic/clojure/3nMn6TiBGOg, which hasn't had any response.

prefers(x,y) visits ancestors by calling parents.invoke() recursively.
This visits the parents in the global hierarchy, not the multimethod's hierarchy.
Is this the intended behavior? Why would that be?

On the assumption that prefer-method should behave the same for a local vs the global-hierarchy, below are 2 unit tests.
MultiFn-prefers-with-local-hierarchy fails with a "Multiple methods" IllegalArgumentException.
MultiFn-prefers-with-global-hierarchy succeeds.

(test/deftest MultiFn-prefers-with-local-hierarchy
  (def local-hierarchy
    (let [h (make-hierarchy)
          h (derive h ::c0 ::b0)
          h (derive h ::d0 ::c0)
          h (derive h ::d0 ::a0)]
      h))
  (defmulti local identity :hierarchy #'local-hierarchy)
  (defmethod local ::a0 [x] [::a0 x])
  (defmethod local ::c0 [x] [::c0 x])
  (prefer-method local ::b0 ::a0)
  (test/is (= [::c0 ::d0] (local ::d0)))))

(test/deftest MultiFn-prefers-with-global-hierarchy
  (derive ::c1 ::b1)
  (derive ::d1 ::c1)
  (derive ::d1 ::a1)
  (defmulti global identity)
  (defmethod global ::a1 [x] [::a1 x])
  (defmethod global ::c1 [x] [::c1 x])
  (prefer-method global ::b1 ::a1)
  (test/is (= [::c1 ::d1] (global ::d1))))

If this is in fact wrong, the fix is pretty easy. I'll submit a patch once it's confirmed this is a real problem.