I almost never use == and instead use = for all equality testing.

(== 9 9.0) seems like the main use case(?)

though I’m guessing you’d often just normalize the types first then use =.

moving on… 🙂

comparing floats for equality with any kind of number always feels tricky

== is for comparing numbers to each other. Its behavior is not defined if you pass it any other type of values.

It’s the choice of exception raised that surprised me, but I’m not going to dwell on it!

see (source =) v. (source ==)

(reduce #(let [[key val] %2]
           (assoc %1 key (inc val)))
        {}
        {:max 30 :min 10})

The function shorthand macro doesn't have an argument vector, so the destructuring has to be done either in a let form, as in the example, or skipped:

(reduce #(assoc %1 (key %2) (inc (val %2)))
          {}
          {:max 30 :min 10})

Or even better for maps:

(reduce-kv #(assoc %1 %2 (inc %3))
           {}
           {:max 30 :min 10})

(although surely it's more readable without short form syntax?)

you are right it should be written as (fn [new-map [key val]]) for readability, but just wanted to know how to use shorthand

If you’re on CLojure 1.11, (update-vals {:max 30 :min 10} inc)

https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L8061-L8075

and the implementation for comparison to our suggestions

Write a small script that uses slurp to read the file, https://github.com/clojure/data.json to parse JSON, then doseq to extract all the sub-objects you want to have and spit them to files again, using data.json for formatting?

Or maybe use jq on the command line

One way to do something like this would be the following:

(let [quantity 85]
  (->
   (some (fn [[max-quantity category]]
           (when (<= quantity max-quantity) category))
         [[50 "A"][80 "B"][100 "C"]])
   (or "D")))

"I don't know how to write the function that can accept a variable number of key-value pairs" Do you just need?:

(defn build-scheme [& key-values] 
         key-values)

Thank you both for your responses. @U03L0CR870T this was exactly what I needed, thank you.

Looking less at the algorithm of the sample scheme, and more at the desired API: Seems tiny wrapper around a map and schemes that destructure key value pairs should set you right up. (Uses condp instead of cond just to expose you to another option.)

(defn abc-scheme [[x n]] ; <- Destructure [k v] pair
  (let [c (condp > n   ; into 2 separate bindings.
            100 "C"    ; <- With logic in your sample,
            80  "B"    ; need to test higher val first
            50  "A"    ; because it shadows other tests.
            "D")]
    [x c]))

(defn classify [m scheme] (into {} (map scheme m)))


(classify {:foo 90
           :bar 60
           :baz 120}
          abc-scheme)
; => {:foo C :bar B :baz D}

Assuming it works (which I haven’t checked), it might be the right thing for your context. A few things jump out at me: • it might be that the surrounding/calling code wants to sort out getting things into their representative type sooner so you don’t have to always take into account the different types the value could be. For example, if it’s a number but you may have got it via IO as a string, consider casting it to a number where you read it • Multi methods shine when you want to do different things based on the dispatch. Taken with my previous point, you would always defer to the same implementation • I think you could collapse the two number ones into :default (look up default multi method if you don’t know what I mean). Possibly with a check and error • Worth considering what behaviour you want for other types like rational, big decimal, big int etc hth Edit: as you said, you’re playing around so maybe my answer isn’t what you’re looking for. Might help someone though!

Also, I think the format call might just do exactly what you want in this particular case. Worth trying.

Which is to make the wider point: there are many times I’ve started down the multi methods route only to simplify the problem down to not needing to use them after all. Something to look out for when you use them, as they do lead to more code/complexity than not needing to dispatch on type at all. I think they really shine when someone else or perhaps some other area of the codebase can further extend them, perhaps long after the initial implementation.

Thanks @U049VPD4BBP - this is exactly what I was looking for. Tell’s me I have the general idea right, but gives me other considerations about how / when / if I might want to actually do something like this. I appreciate your response!

I actually revised it a bit for other numbers since I posted that to:

(fn [n precision]
    (if (number? n)
      java.lang.Number
      (class n))))

Nice 👍 You can use keywords as the “matchers” (I forget the actual name, if I ever knew it). The reason I say this is that your defmethod can have :number and then if there’s something that doesn’t extend/implement the Java interface/type you can still dispatch to that. You’ll have to decide which makes most sense in your domain. In this case I think java.lang.Number is a good choice as it’s likely all numbery things will extend it, e.g. https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Ratio.java - Sorry for the slightly abstract wordy explanations, on my mobile so can’t really write code easily

Oooh cool - thanks @U049VPD4BBP More good “food for thought”. I’m not (yet) using Clojure for work things, I’ve just been enjoying it in the evenings. I’m like learning about stuff like this and how to think more “functionally”.

I definitely recommend taking a look at The Joy of Clojure @U0250GGJGAE https://www.manning.com/books/the-joy-of-clojure it goes beyond the the language into how to leverage the features it has. Some really elegant code snippets in there too

(Make sure to get the second edition https://www.manning.com/books/the-joy-of-clojure-second-edition)

Nice - thanks @U049VPD4BBP will take a look!