it's pretty easy to check at the repl

(instance? java.util.Collection [1 2]) ;; => true

Maps implement java.util.Map

lazy-cat will concatenate lists laziy and since we initialize the lazy seq with [0 1], we can refer to earlier elemnts in the list to define the later elements. When we try and take more than 2 elements from the sequence we get to the (map + (rest fib-seq) fib-seq) term (which is also lazy). Here map will apply the function + to the two lists it's given in sequence, and rest will return the given sequence with the first element removed. So to calculate the third element, we apply + to the first element of (rest fib-seq) (which is 1) and the first element of fib-seq (which is 0) to get 1 and include that in the sequence. Then the fourth element is 1 + 1, the fifth is 2 + 1 and so on. Does that make sense?

I am a beginner too... so Please bear with me... as fib-seq is defined as lazy it will not be evaluated when you define it. It'll however get defined when you call upon it... e.g. (take 10 fib-seq) When you do this... clojure env tries to figure out what the he*k is fib-seq... so it goes to the definition

(lazy-cat [0 1] (map + (rest fib-seq) fib-seq))

(map + (rest [0 1]) [0 1]) => (1)

(cat [0 1] (1)) => (0 1 1)

(0 1 1 2)

(0 1 1 2 3 5 8 13 21 34)

Thanks for long write @U022LK3L4JJ and @U0P0TMEFJ, That helped one question I have is , does it in iteration? like take 0 take 1 take 2 till take 10 ?

I'm not sure I understand the question. A lazy seq is a value in that once it's calculated an element, it's cached and won't be recalculated. So if you (take 10 fib-seq) it will do the work to calculate the first 10 elements, then if you (take 11 fib-seq) it will only need to calculate the 11th element.

ahh. I got that!!! thanks @U0P0TMEFJ

thanks @U022LK3L4JJ

👍 ... btw, what I said is not strictly speaking true, since clojure generally chunks generating lazy sequences for performance, but you can usually ignore that. If you find that you can't ignore chunking of lazy seqs, you're probably trying to use them for something they're bad at, like side effects ;)

What would this print ?

right now it is printing nil

Yeah, that's pretty normal

Instead of ids and titles

How do I select the values with let?

You have a vector. You want to select every :i and every :title ?

yeah

vector of maps

Waht do you want in i ? [1 2 3] ?

(1 2 3)

Because no, you can't deconstruct a vector with maps inside with this syntax.

How to deconstruct it then?

You can't, afaik. You need to map over data:

(let [i (map :id data)
      titles (map :titles data)]
...

Oh, sorry, work is calling, brb.

But that would be calling the function twice

okay no worries

Store the data you get back. That's what let is for. Sorry, I thought that data was the result of the function, habit.

How to do it in one pass?

cljs.user=> (def data [{:id 1, :title "a"} {:id 2, :title "b"} {:id 3, :title "c"}])
#'cljs.user/data
cljs.user=> (map #(let [id (:id %)
       #_=>             title (:title %)]
       #_=>         (println (str id ". " title)))
       #_=>      data)
1. a
2. b
3. c

I don't get why you'd need that. If that's your need, I think you need to rething your data function to serve you your data in the correct way. But otherwise, you can do it with map destructuring and a reduce :

(let [{:keys [i titles]} (reduce (fn [acc obj] (-> acc
                                                   (update :titles #(conj % (:title obj)))
                                                   (update :i #(conj % (:id obj))))) {:titles [] :i []} (data))]
(println i)
(println titles))

I don't caution this approach, it's ugly as hell imho. There may be a cleaner way to do this 👀

if you want to get all the id's in one list, and all the titles in another, this might help

(let [[ids titles] (apply map vector (map (juxt :id :title) [{:id 1, :title "a"} {:id 2, :title "b"} {:id 3, :title "c"}]))]
    (prn 'ids-> ids 'titles-> titles))

I knew there was a way to do that with juxt, but I couldn't figure it out.

The apply map vector idiom is pretty cool too. You can almost think of it as rotating a matrix 😉

(->> [[1 2 3]
        [4 5 6]
        [7 8 9]]
       (apply map vector))
  ;; =>
  ;; ([1 4 7]
  ;;  [2 5 8]
  ;;  [3 6 9])

so we can (map (juxt :id :title) ...) to get ([1 "a"] [2 "b"] [3 "c"]) and then "rotate" the data by taking each element from each list in turn and making a vector out of them using (apply map vector ...) ... does that make sense?

Oh yeah, I just had forgotten that map could take n collections as arguments. Thanks for the "think of it as rotating a matrix" tip 🙂

Strictly speaking though, you do not do it "in one pass" 😛

I guess it depends on what you mean by "in one pass"? Because map and apply are both lazy, it'll consume ram until the last element of the data is available, but sure, I guess there are 2 loops in there that are proportional to the size of the input list. Using reduce is probably the best way to cut the number of loops down .. as you mentioned 😉

For original problem, ‘for’ is clean

that’s a good point

I think the same goes for use-eid and new-eid ... they can both be auto-gensym'd too ... right?

yes, i thnk you’re right

in this form (game.core.eid/make-eid ~'state) do you mean to shadow state like that? or could you get that from ~(second action) ?

We could do that, yeah!

also .. isn`t ~(cons 'list (drop 3 action)) the same as (list ~@(drop 3 action)) ?

if th is passed a function (as in your example (make-eid state)) won't it execute that function multiple times?

not sure if that's a problem for your code, but it looks like bad macro practice 😉

oh it’s very bad. someone new to clojure wrote this back in 2016 and it’s now being used in 604 places in our codebase, so most of my attempts to change/fix it have gone poorly lol

😉 ... we've all been there ...

(defmacro wait-for
  [action & expr]
  (let [awaited-fn `(fn [inner#]
                      (let [~'async-result (:result inner#)]
                        ~@expr))
        th         (nth action 3)]
    `(let [th#      ~th
           use-eid# (and (map? th#) (:eid th#))
           new-eid# (if use-eid# th# (game.core.eid/make-eid ~(second action)))]
       (game.core.eid/register-effect-completed ~(second action) new-eid# ~awaited-fn)
       ;; current
       #_ (if use-eid#
         ~(concat (take 3 action) (list new-eid) (drop 4 action))
         ~(concat (take 3 action) (list new-eid) (drop 3 action)))
       ;; new
       (apply ~@(take 3 action)
              new-eid#
              (if use-eid#
                (list ~@(drop 4 action))
                (list ~@(drop 3 action)))))))

i appreciate you reading it so closely tho, it’s really helpful. i’m still fairly new to macro writing and have trouble wrapping my head around it sometimes

yeah ... it's a tough one to master ...

that's why all the advice is "only write macros if you have to" 😉

you mentioned worrying about nesting wait-for 's ... I would have thought that writing ~'async-result would have created problems with nesting

oh yeah, that is def something i worry about, but likewise i have no good way of handling it. an anaphoric macro is the best i’ve come up with for that

is that cos you want to pass the result to the func in a random position?

yeah, i want to expose the result of (draw state :corp 1) (the drawn card) to the later functions:

(wait-for (draw state :corp (make-eid state) 1 nil)
          (system-msg state :corp (str "drew 1 card: " (:title async-result)))
          (effect-completed state :corp eid))

otherwise, i have to put the “result” somewhere on the state map atom and then i have to deal with removing it at some later point (difficult, error prone) or leaving it on the atom forever (effectively a memory leak)

well ... it depends on how much refactoring you can get away with 😉

usually you'd pass the bindings in

i mean, on the one hand i’m experimenting with rewriting the whole engine cuz this one is a mess and i hate working with atoms, but on the other hand, i don’t want to rewrite 42k lines, so anything less than that is a win

(wait-for [{async-result :result}]
            (draw state :corp (make-eid state) 1 nil)
            (system-msg state :corp async-result)
            (effect-completed state :corp eid))

(defmacro wait-for
  [bindings action & expr]
  `(let [th#      ~(nth action 3)
         use-eid# (and (map? th#) (:eid th#))
         new-eid# (if use-eid# th# (game.core.eid/make-eid ~(second action)))]
     (game.core.eid/register-effect-completed ~(second action) new-eid# (fn ~bindings ~@expr))
     (apply ~@(take 3 action)
            (if use-eid#
              (list ~@(drop 4 action))
              (list ~@(drop 3 action))))))

That’s very cool

Edited cos I made an obvious mistake 😉

my advice with macros is to do as little as possible in the macro and try and turn it into functions asap ... so I would try and get to something like

(defn wait-for* [[func st quay th & args :as action] side-effects]
  (let [[eid args] (if (and (map? th) (:eid th))
                     [th args]
                     [(game.core.eid/make-eid st) (cons th args)])]
    (game.core.eid/register-effect-completed st eid side-effects)
    (apply func st quay eid args)))

(defmacro wait-for [nom bindings [func st quay th & args :as action] & expr]
  `(wait-for* ~action (fn ~nom ~bindings ~@expr)))

(comment
  (wait-for* [draw state :corp (make-eid state) 1 nil]
             (fn [{async-result :result}]
               (system-msg state :corp async-result)
               (effect-completed state :corp eid)))

  (wait-for something [{async-result :result}]
             (draw state :corp (make-eid state) 1 nil)
             (system-msg state :corp async-result)
             (effect-completed state :corp eid))

  )

That’s very cool! Thank you so much for the help

to be fair, you could make the extras optional

(defmacro wait-for [ & body]
  (let [[nom body]      (if (symbol? (first body)) [(take 1 body) (next body)] [nil body])
        [bindings body] (if (vector? (first body)) [(first body) (next body)] [[{'async-result :result}] body])
        [action & body] body]
  `(wait-for* ~(vec action) (fn ~@nom ~bindings ~@body))))

static + dynamic*: calva for vscode.

This is a pretty good overview of many tools available from a vimmers perspective, if that helps 🙂 https://github.com/rafaeldelboni/nvim-fennel-lsp-conjure-as-clojure-ide

@UL6NS3E7P that sounds about right. note that you can use static + runtime together in one IDE

@U04V15CAJ like calva does?

yes

hmm. Any potential performance issues if I use clojure-lsp and vim-iced together with neovim?

Not that I'm aware of. I'd highly recommend combining static and dynamic tooling.

I think iced overlaps with LSP in some ways for static / refactor tooling but not in a bad way. They should both happily handle different useful things 🙂

The Neovim LSP tooling has been fantastic for me so far!

cool. I am using iced for now, and will add lsp when needed. Thank you all for the help!

I guess I feel obligated to add Tutkain for Sublime Text in the latter category (with a smattering of static analysis for highlighting locals). You can optionally use either clojure-lsp or clj-kondo for static analysis / linting.

@U4ZDX466T updated. Thanks.

After thinking on this a bit, I decided I am more comfortable with static analysis, and went ahead with clojure-lsp. Now I need to decide which tool to use to integrate REPL with vim. vim-fireplace, may be? I don't want to run into conflicts by mixing lsp and conjure/iced.

I'd second @U38J3881W’s recommendation above and adapt it to your needs. It provides a Neovim config using Fennel that wires up both clojure-lsp and Conjure. I've used Conjure as my primary Clojure dev environment for months now with no complaints: https://clojurians.slack.com/archives/C053AK3F9/p1631114227261500?thread_ts=1631114104.260100&cid=C053AK3F9

Clojure-LSP is very configurable, so it is a simple Matt of turning features off if not needed. Conflicts tend to be in formatting and UI elements, if any occur. The Clojure-LSP website has lots of useful information about the features and clients (editors) https://clojure-lsp.io/clients/

Whatever you do, favor dynamic REPL over static all day every day. Having both is the best of both worlds, but the dynamic live programming is where its at

There isn't an either/or choice anywhere I think

I just mean, don't only use static analysis, you'll be missing out on the best part of Clojure if you don't learn how to leverage the REPL for live programming. Which is a comment targeted at: > After thinking on this a bit, I decided I am more comfortable with static analysis, and went ahead with clojure-lsp Use both ideally, but its really worth taking the time to learn how to leverage a REPL in-IDE.

Agreed

And maybe if it was not clear, they are always available in combination. In VSCode, Emacs, Vim, IntelliJ and all that, you'll all be able to have both a live REPL and some static analysis happening together. You can set them up to have only one or the other, but both is the dream. Cursive does both static and dynamic. Emacs does both static and dynamic. VSCode does both static and dynamic. Vim I'm not sure, but I'm under the impression it does both as well.

@U0K064KQV interesting. Does the community have a go-to guide or video on REPL driven development?

@U11SSJP2A I am a bit hesitant on adopting the guide that @U38J3881W pointed to, because it is in fennel. I already have nix as the ‘exotic’ element of my configuration, don’t want to add more. Also, the ‘how to use’ section in that guide does not give me confidence that this configuration will integrate smoothly with my existing neovim configuration.

I recommend Stu Halloway's talk on REPL-Driven Development as a good starter. I gave a long talk/demo to London Clojurians also called REPL-Driven Development (Clojure's Superpower) and I have a couple of short videos about it on my YouTube channel.

If you're willing to pay for material, Eric Normand's http://PurelyFunctional.tv has an incredible REPL-Driven Development course.

Stu's talk: https://vimeo.com/223309989

My long talk: https://www.youtube.com/watch?v=gIoadGfm5T8

My YT channel: https://www.youtube.com/c/SeanCorfield_A

Good material from Practicalli on this topic: https://practical.li/clojure/repl-driven-devlopment.html

Eric's course https://purelyfunctional.tv/courses/repl-driven-development-in-clojure/

https://clojure.org official docs on RDD: https://clojure.org/guides/repl/enhancing_your_repl_workflow and subsequent pages

I really should make a blog post about this...

I've found this 2min video shows nicely what's cool about it: https://www.youtube.com/watch?v=rQ802kSaip4

Just try installing vim-iced: https://liquidz.github.io/vim-iced/#installation (since you said your a neovim user)

@U0K064KQV how do you achieve linting? I see that neither iced (https://github.com/liquidz/vim-iced/issues/355) nor conjure (https://github.com/Olical/conjure/issues/68) want to support linting outright. Both recommend clj-kondo for linting.

@U04V70XH6 (I always read your last name as cornfield! Sorry for that) Thank you for the links! I had already gone through your video a few days ago. I am halfway through Stuart’s talk, and it’s enlightning in many ways.

The official website is very good at hiding away quality material.

> Clojure-LSP is very configurable, so it is a simple Matt of turning features off if not needed. This looks like the way to go @U05254DQM I don’t have the screenshots to back me up, but clojure-lsp, at least with its default configuration, failed to find documentation for a few symbols (external library like clj-time, Java symbols, etc.), while iced found them for me. If anyone has any idea on what’s going wrong wrt clojure-lsp here, please let me know. For reference, my project uses deps.edn.

#lsp channel is very helpful in that regard.

Ya, just install clj-kondo as well for linting using your preferred choice as explained here: https://github.com/clj-kondo/clj-kondo/blob/master/doc/editor-integration.md#vim--neovim

And you can set vim-iced to use static analysis from clj-kondo too as explained here: https://liquidz.github.io/vim-iced/#static_analysis_clj_kondo