Ah, I am discovering distinct and juxt! This is muuuch more succint and readable.

user=> (group-by first (map (juxt :store :total) input-data))
{"Mitesh" [["Mitesh" 5.9] ["Mitesh" 5.5]], "Moore Wilson" [["Moore Wilson" 85.16] ["Moore Wilson" 33.45]], "New World" [["New World" 75.26] ["New World" 84.28]], "Pak n Save" [["Pak n Save" 26] ["Pak n Save" 200.36]]}
user=> (reduce-kv (fn [acc k v] (conj acc {:label k :data (map second v)})) [] *1)
[{:label "Mitesh", :data (5.9 5.5)} {:label "Moore Wilson", :data (85.16 33.45)} {:label "New World", :data (75.26 84.28)} {:label "Pak n Save", :data (26 200.36)}]

(that reduce could add the :backgroundColor as well, by doing a lookup on store-color of the k value)

So here's the whole thing in the REPL:

user=> (def store-color {"Moore Wilson" "#88A096"
  #_=>           "Pak n Save" "#BBAB8B"
  #_=>           "Mitesh" "#8A4F7D"
  #_=>           "New World" "#EF8275"})
#'user/store-color
user=> (def desired-data {:datasets (->> (group-by first (map (juxt :store :total) input-data))
  #_=>                                   (reduce-kv (fn [acc k v] (conj acc {:label k :data (map second v) :backgroundColor (store-color k)})) []))
  #_=>                    :labels (distinct (map :month input-data))})
#'user/desired-data
user=> desired-data
{:datasets [{:label "Mitesh", :data (5.9 5.5), :backgroundColor "#8A4F7D"} {:label "Moore Wilson", :data (85.16 33.45), :backgroundColor "#88A096"} {:label "New World", :data (75.26 84.28), :backgroundColor "#EF8275"} {:label "Pak n Save", :data (26 200.36), :backgroundColor "#BBAB8B"}], :labels ("06/21" "07/21")}

Sometimes simplifying the data before processing can lead to a much simpler transformation.

amazing. I'm going to recreate it now to work through/comprehend it.

(disclaimer: I've been doing Clojure in production for just over a decade at this point -- it does take time to internalize the core functions because that's a very broad space!)

Ah, the use of the threading macro is nice. I like how your implementation clearly shows the intended shape of the data.

e.g., it is basically (define data {:dataset (fn) :labels (fn)}).

which is easier to understand from a general shape. I think I had some internalized feeling that I should only use the input-data value once.

and I like how you transform it separately for labels and datasets, so the initial shape for each is easier to work with. Thank you for this!!!

It's true that it makes two passes over the input data. That may or may not be a performance consideration "in the wild". Making a single pass adds complexity so it's a trade off about which is faster overall.

for lists, you should use nth

yes, I'm just confused why it's like this (always returning nil instead of throwing)

won't that hide silly programmer errors?

and make them harder to debug

its more around the thought process of https://lispcast.com/nil-punning/

https://lispcast.com/what-is-nil-punning/

thanks, I'll check it out :)

> why can't I use `get` on a list? @U01UDS4A1K8 This can be annoying, yes. However get is intended for hash-maps (i.e. associative data structures). Ref: the function signature in (clojure.repl/doc get) . It only accidentally works for Vectors, because they are also associative data structures under the hood, just like hash-maps, but keyed by index position instead of arbitrary keys. Clojure lists are not associative underneath. Comparing the interfaces these structures implement my prove to be illuminating. Look for clojure.lang.Associative:

user=> (supers (type '()))

user=> (supers (type []))

user=> (supers (type {}))

user=> (supers (type #{}))

Just to be sure: Both nth and get have a parameter where you can pass in a default value, which it will return in case it doesn’t find the thing.

And you can kind of think of nth as an iterative next , so it will make sense why it would return nil

(nth nil 0)=> nil

(next nil)=> nil

True, but (get '(any list ...) any-index 42) will always return 42. i.e. the default return, in case of a list, doesn't alter OP's original conundrum. Instead of nil, they'll just get back 42 each time.

Yeah, I wanted to add something to: > yes, I’m just confused why it’s like this (always returning nil instead of throwing) Because I just recently also had trouble to understand nil and how different core functions work with it and what it means etc.

> get is intended for associative data structures > [...] > lists are not associative why no exception (type error) then?

I think trying to make sense of it is overall detrimental haha

No it’s not! It has very much to do with how Lisps in general treat nil and polymorphism.

> why no exception (type error) then? That's a very good question, and AFAIK, the answer to that is an age-old debate. I personally prefer to "define errors out of existence", as John Ousterhout puts it in this lecture: https://www.youtube.com/watch?v=bmSAYlu0NcY&amp;t=1315s If the semantics of get is to get a thing at a position or <default value> or nothing, and if it's already possible to use nil or some custom sentinel value like ::error/not-found for semantic error handling, do we need to force an Exception? I don't know the right answer. However it stands out that get and nth are not symmetric in this regard.

user=> (get 1 1)
nil
user=> (get "foo" 1)
\o
user=> (nth 1 1)
Execution error (UnsupportedOperationException) at user/eval10616 (REPL:1).
nth not supported on this type: Long

user=> (nth "foo" 1)
\o

get and nth and friends flow nicely into if-let and when-let

And into higher order functions such as filter and some

ah, so get will always succeed no matter the type? that's better - I thought it was just lists that make it return nil

one of my favorite clojure absurdities:

user=> (= (get get get get) get)
true

> why no exception (type error) then? My comment on this is that Clojure rarely wants to throw exceptions. It concedes to them when doing interop (which in turn means that (nil) will cause a NullPointerException) but in general, sticking to clojure.core should not lead to an exception anywhere. If not for that, then I would think that it would be appropriate to have some kind of exception. However, it can’t be a ClassCastException, since what actually happens in get is that it looks for the ILookup interface, but if that’s not present then it does a couple of fallbacks, such as doing nth on arrays and strings. Only when all other options fail does it revert to nil (or the not-found value). Regardless as to whether it’s a good idea, it could potentially break existing code to change it, so it will never get changed.

I'm too lazy to configure emacs so I use this https://github.com/hlissner/doom-emacs , it setups vim keybindings

Thanks — I ended up going the Spacemacs route and am modifying: https://practical.li/spacemacs/. I prefer the normal Emacs key-bindings, so I’ve had to remove the VIM options there which are enabled by default.

I've been adding in the command names into the Practicalli Spacemacs book, for those not using Evil (or Spacemacs). If there is anything not clear or missing, let me know.

There is also a #spacemacs channel for specific Spacemacs related help

Thanks, @U05254DQM! I was impressed with the setup you were using a few weeks ago during the SciCloj session

(partition 2 1 [1 2 3 4]) ;-> ((1 2) (2 3) (3 4))
(partition 3 1 [1 2 3 4]) ;-> ((1 2 3) (2 3 4))

(defn the-fn [n stuff]
  (partition n 1 stuff))

thanks!

I use the vscode neovim plugin together with calva. Kind of works nicely. As for my workflow dealing with your issue - what I do there is to delete the t/ (i dont let parinfer autoformat), press tab which realigns the indent and then format with shift-tab

But yes you cannot use that all in vim

I installed parinfer-rust and now everything seems to be working as desired. Thanks!

for that use case, I'd make a higher order function that returns the reader function, and use def to make the var, in order to use def programmatically you need a macro

Ah thanks!! perfect.... for some reason a macro did not occur to me

i've got the higher order function written was just blocked on this, thanks muc

h

it's "macro contagion" - since def is a macro, you can't make a form that extends its functionality without making another macro

I tend to be highly suspicious of macros that wrap def, for example when debugging it's frustrating to see a function misbehave and not be able to find the definition

fair point, it's like 5 defs i may just type them out

You can use intern

But yeah if it’s 5 defs and just an effort to not repeat code, then it’s not worth it