Fork me on GitHub
Jon Olick02:06:38

why does sort put its results in a list?!

Jon Olick02:06:59

ok so the code says it converts it to an array, then does a seq on the results

Jon Olick02:06:13

so its not really a list

Jon Olick02:06:15

its a seq of a java array


anyone know if there is a way to get zprint to format by placing trailing parens on their own lines?

(defn hiccup [[tag & body]]
	(prn "tag" tag)
	(prn "body" body)
    (if true
(I know this is a cursed question, but I only want to temporarily format files like this as I'm writing them, as I think it makes editing easier, then reformat them into the correct style before commit, which makes reading easier


How come you find editing easier this way? Are you using some kind of structural editing (for example paredit)?


I am using some paredit functions, mainly slurp, barf, and a function to move the cursor across entire sexps. With the paredit way (at least the way I do it, but maybe there's something better), whenever I want to add another expression at the end of a list of expressions, or somwhere inside it (which tends to happen quite often), I do the following:

(defn x []
   (nested (call goes here)))
So say I want to add something after nested , then I need to move the cursor at the start of nested, move to the right one whole sexp, then type enter to make a new line, then type my expression. if the parens were not stacked at the end, I could just click at the end of the line and press enter, which is easier and requires less key combos/thinking. Same thing if I wanted to add something after (call ...) , either count parens to figure out where it goes, or place cursor before, move a whole sexp, then add there


I kinda feel like if files were formatted in the cursed way, then there wouldn't be much of a need for structural editing at all 🤷


Does your editor show matching parens? Either by highlighting the other paren when moving the cursor, or using matching colors? That way you can go to the end of the line, then go left until the right paren lights up, without having to "count". You should never have to count parens :)


Yeah, it does do this, but I feel like that's more like "assisted counting" - still some mental/mechanical overhead to a super common editing operation


The things you want to do should only be one or two key presses if the editor supports structural editing.


@U05254DQM would it be similar to the paredit workflow I described above, or something else?


either way I'm still interested in my original question, because without trailing parens all on the same line, all the scenarios I've described above become 0-keypress changes, with no mental overhead of thinking about what key to press, where to move the cursor, and what operation you need to do - just click at the end of the line and insert what you want


much like how calva has special formatting for rich comments:


same idea but apply it to all forms, not just rich comments


In answer to the starting question, highly unlikely. removing that kind of formatting is one of the things those formatting tools were written for. If structural editing is not for you, then switch off automatic formatting in the editor you use and apply the formatting tool when finished.


I have updated a deeply nested map like below , Can I update it in better way ?

(update-in m [:a :b :c ](fn []
                     id {:d {:e {:f value}}}}))


I’m assuming there’s a typo in this example somewhere since a function is part of the “key-path”?


sorry updated it


Okay! Now I see that run-id is effectively unused, but I assume that if some condition is true then you want to assoc-in at that nested level? I’m not sure there’s a much more elegant way than the following examples; the first is for if there is no “conditional”, and the other two is for if we want to check for something to be true/false before updating:

((fn [m value]
     (update-in m [:a :b :c] assoc-in [:d :e :f] value))
   {} 2)
  ; => {:a {:b {:c {:d {:e {:f 2}}}}}}
  ((fn update-if-true [m true? value]
     (update-in m [:a :b :c] (fn [nm]
                               (if true? 
                                 (assoc-in nm [:d :e :f] value)
   {} true 2)
  ; => {:a {:b {:c {:d {:e {:f 2}}}}}}
  ((fn update-if-true [m true? value]
     (update-in m [:a :b :c] (fn [nm]
                               (if true?
                                 (assoc-in nm [:d :e :f] value)
   {} false 2)
  ; => {:a {:b {:c nil}}}


For more advanced and/or messy transformations I’d also consider Specter:


assoc-in is not replacing values, rather it is just adding up values


If you want to remove the part of the nested map that starts at :d then assoc-in isn’t a good choice, that’s true! In that case I’m not sure there’s a much better way to update this nested map


what do you expect as a result?


hmmm.. , But thanks for your response!


(def m {:a {:b {:c {:s {:d {:e {:f value}}}}}}})
I want map as
{:a {:b {:c {:t {:d {:e {:f value}}}}}}}


and I presume some other keys might occur anywhere in original map, right?


yes , it just replaces the middle key in map


and what if the map under the key :c already has key :t ?


no. :t is the replaced key , , I just have to replace :s to :t


does it looks like what you've been talking about?


Sorry If I am convening it wrong!!!! It is not a rename key, I have to update whole map {:t {:d {:e {:f value}}}}


I am sorry, , for your confusion! I wrote wrong


could you give an example output for the map like this:

(def m {:a {:b {:c {:s {:d {:e {:f 42
                                :x 42}
                            :x 42}
                        :x 42}
                    :x 42}
                :x 42}
            :x 42}
        :x 42})
I just add an :x on every level


(def m {:a {:b {:c {:s {:d {:s {:id1 {:address1 value1}}}}}}}})

I wante map as {:a {:b {:c {:t {:id2 {:address2 value2}}}}}}


then assoc-in should work

(assoc-in m [:a :b :c] {:t ...})

popeye09:06:54 , I tried this but it will just add one more key along with other key tight ? I meant it will have both :s and :t keys


No, why's that? My snippet will give a complete replacement for a value under key :c


oh so no update-in required here ?


as far as I understand - no


here also we have to pas values as

{:d {:e {:f value}}


(assoc-in m [:a :b :c] {:t {:d {:e {:f value}}})


that works! Thanks for you response @U04V4KLKC 🙂