you mean key de-structuring of rest sequences correct?

oh, right, yes I mean keys of rest sequences, not keys generally,

This is a test that i'm adapting. Previously it receive multiple arguments and now i'm adopting a config map instead so i won't need change arity again

is the map literal above a pseudo-code?

No

Let me show you the test

(create-table-sql ..db.. :test-table (as-checker (contains {:id anything}))

so I wold turn that into {:name :test-table :col-specs [(as-checker (contains {:id anything}))]}

Il'l Check that . thanks

https://lacinia.readthedocs.io/en/latest/tutorial/pedestal.html?highlight=graphiql#id6

(lp/service-map {:graphiql true})

lp = com.walmartlabs.lacinia.pedestal

I cannot see the project :S

you need to enable it by passing the config above

Sorry I posted my work link LOL

it should work now

😄

Yup. I see it 🙂 It also seems like a good place to start is the lacinia tutorial on this page

Yes, the tutorial is fantastic! Highly recommended. If you are looking for a client library then I would suggest looking at re-graph library - https://github.com/oliyh/re-graph

Cool 🙂 Will definitely keep in mind. A bit rusty on clojure, but I’ll manage. The major new thing is GraphQL, possibly getting the tooling stuff working (ClojureScript was somewhat temperamental at times when I last did Clojure). But the combined solution seems awesome

I use the following idiom: (some (fn [x] (when (pred x) x)) xs)

Thanks!

(->> my-list (filter my-pred) (first)) will not keep searching the rest of the list. filter returns a lazy sequence

some is what you're looking for, but > even if a match is found, it will keep searching the rest of the list. Just that rest of that chunk, since filter is lazy

user=> (first (filter #(do (println %) (= 5 %)) (range 10)))
0
1
2
3
4
5
6
7
8
9
5
user=>

user=> (first (filter #(do (println %) (= 5 %)) (range 100)))
0
1
2
3
4
5
6
...
26
27
28
29
30
31
5
user=> 

yeah good point

this version prints once, and is efficient, you'd want to wrap it in something much less weird looking though

(transduce (filter (fn [x]
                     (println x)
                     (even? x)))
           (completing (fn [acc el]
                         (reduced el)))
           :invalid
           (range 100))

maybe better?

(eduction (comp (filter (fn [x]
                          (println x)
                          (even? x)))
                (take 1))
          (range 100))

Oooh I like that.

of course you'd put it in a function where you plug in the fn and the coll (and maybe call first on the result too), because in my experience collaborators go to a dark place when they see things like eduction

Of course

Although on one hand, I'm working with a list < 32 items long on the other filter feels like the wrong tool for the job.

(some #(do (println %) (= 5 %)) [1 2 3 4 5 6 7 8 9 10])
1
2
3
4
5

oh, I thought some returned a boolean instead of your item

maybe that's OK in your domain, if so I missed that

It does, but you can wrap it in a when

to get the original value

I think someone mentioned some goes through all values.

😛

(loop [xs (range 100)]
  (if (and (first xs) (even? (first xs)))
    (first xs)
    (recur (rest xs))))

At this point I'm just considering options. Personally I think that eduction very explicitly describes the intended behavior.

probably the end condition should be empty? rather than truthiness of the head

(defn find-first
  [f xs]
  (->> xs
       (reduce #(if (f %2) (reduced %2) %1) nil)))

(find-first #(do (println %) (= % 5)) [1 2 3 4 5 6 7 8 9 10])
=> 
1
2
3
4
5
5

oh yeah that's probably the neatest imo

reduce shares the property with eduction of utilizing the fast iteration path for supporting collections

(defn find-first
  ([f xs]
   (find-first f nil xs))
  ([f not-found xs]
   (->> xs
        (reduce #(if (f %2) (reduced %2) %1) not-found))))

also that function could be #(when (f %2) (reduced %2))

Oooh

but that doesn't respect your not-found

Well, not if I want that default yeah

clojure does something called "locals clearing" to prevent massive heap usage with lazy-seqs, and there's a compiler option to turn that off so debuggers can see your locals

the local values are intentionally deleted otherwise, so there's nothing for the debugger to find

Yes, I know about the flag Now I wonder where to actually see these locals in a specific profiler's UI

oh, carry on

varargs keys destructuring in function arg lists?

that's the big one I can think of

oh! you mean the optimization to just use the map if it is one

yes

*me hasn't been getting enough sleep

I think you are misreading the conditional

it only creates a map if it is a seq

oh right!

*me hasn't been getting enough sleep

Pretty sure not since there's no a JVM-powered formatter that vertically aligns things No formatter -> no linter :)

One could toy with Emacs in batch mode if you really consider it worth the effort. IMO emacs isn't exactly the best canonical formatter (the best being a mixture of cljfmt, cider and hand-tuned things)