fnil lets you specify a first arg if the initial first arg is nil

(defn test1 [acc, v]
  (let [target (keyword (str/lower-case (str (first v))))]
    (update acc target (fnil conj []) v)))

woot! Thank you, I was not familiar with fnil. I appreciate you!

as a side note, this use case is a candidate for group-by:

(group-by (comp keyword str/lower-case str first) ["Abby" "Bryan" "beakman"])
=> {:a ["Abby"], :b ["Bryan" "beakman"]}

lol… perfect. So often I learn a better way here, thanks again.

Hi! Is the repl connected?

I found the problem. For some unknown reason, this was added to the settings.json

"calva.keybindingsEnabled": false

Great! Maybe you happened to trigger the command Calva: Toggle Keybindings Enabled. We used to have a default keybinding for it, but that created a lot of confusion. 😃

Hi! Calva’s debugger is not started like that. A Clojure program is always running, so in effect the debugger is always running. You need to place breakpoints for the debugger to stop at, one way is to instrument a form. See: https://calva.io/debugger/ That said. Very often you don’t need the debugger. Inline def’s cover a lot of that use case. Inline def means to place a (def x something) in a form, where something is a a local variable. I often do (def something something), even. There are tools for making this even more convenient, like snitch: https://github.com/AbhinavOmprakash/snitch

Thank you very much indeed for your help

Yep - all there and working great. Thanks once again.

I've solved this... the only thing needed to fix this was to pass the Hello, within a call to str

The percent thing is normal for query params in a URL. For example, if you go to wikipedia, type 'hello,' in the search box, hit enter, and look at the URL at which you end up, you'll see (among other params) search=hello%2C. https://en.wikipedia.org/wiki/Percent-encoding has a longer discussion of this. Tangentially, I think if you mouse over the link previews, there will be an X that will let you remove the preview (if you want to banish the Adeles).

sh attempts to capture all the output into a string and return it, so it needs to wait until the process exits

My general solution is that there's no shortcut: I just develop familiarity with the seq API and rely on jump-to-definition.

Ok.. So in this example, I’m thinking I should look at seq/concat/take/drop and if they all return lazy sequences, then my function should also be lazy. Is that a reasonable starting point?

I just did that, in this case - it appears that seq is not (necessarily?) lazy. So my use of it may be resulting in a non-lazy result.

But I just don’t really know how to know.

seq doesn't have anything to do with laziness other than it can be used to force a single layer of laziness to determine if a lazy seq is empty (nil) or not

In general the only time you need to call it is when you want to do something like (if (seq s) ... ...) Where what it is being used for is testing if s is empty

I am using it here so that the function will handle maps

e.g.

(remove-nth {:a 1 :b 2 :c 3 :d 4} 2)
;; => ([:a 1] [:b 2] [:d 4])

Drop and take internally call seq on their args

And that is the other thing seq does, it gets a seq over things that are not seqs

But most(all?) of the functions that operate on seqs do that coercion internally

Oh lol. Ok, I see that now. I thought I was getting an error without it, but I see now that I don’t need it (thanks). Updated function:

(defn remove-nth [coll index]
  (concat (take index coll) (drop (inc index) coll)))

But the laziness

I think it’s maintaining laziness. That’s my my question.

I just found realized? I think that may be what I need to confirm:

(def t1 (remove-nth {:a 1 :b 2 :c 3 :d 4} 2))
;; => #'cities/t1
cities> 
cities> (realized? t1)
;; => false

I think that means it’s still lazy.

realized is nonsense

oh?

I mean it sort of does stuff, but it is not useful

Because the thing about ISeq is it is modeled on a cons cell type of list, it is really the interface for a single cell

And as a consequence the laziness built on top of it exists at a cell at a time

So you can have a seq where the first item is "lazy" and the rest of the seq is not

Oh ok. Darn. Can you confirm if my function is lazy, e.g. do you know and if so - how do you know?

Another issue is chunked seqs

Strictly speaking clojure's lazy seqs are more like "non-strict seqs" in that there is no guarantee that if you walk it one element at a time that only one element at a time is realized

For some kinds of seqs you can have a kind of batching behavior where they realize in chunks of 32 elements

It is best to think of lazy seqs as an optimization the runtime can do to fuse multiple traversals into a single traversal, and to avoid caring about things being lazy or not

This actually came down to my desire to add a doc string to this function. concat has a doc string that says: “Returns a lazy seq …” I realized when writing my doc string here that I don’t know if my function is returning a “lazy sequence” (in the way that clojure core thinks about lazy sequences). So I am trying to document it accurately.

Concat returns a lazy sequence

Yes, but does my function?

A lazy sequence and the sequence being realized or not are different things

Your return the result of calling concat, concat returns a lazy sequence

If calling + returns a number, and your function returns the result of calling +, what does your function return?

It also calls take and drop, given all that would you say my function can still be described as “returns a lazy seq..” ?

Not sure what you are trying to say?

I am trying to understand if documenting my function as “Returns a lazy seq…” is an accurate statement. I wasn’t sure, because it’s using several functions like concat , take and drop.

a lazy seq is a data type, like a hash map

I do understand what it is, I was trying to understand if it’s accurate to say that my function returns a alzy sequence.

So your function might do all kinds of stuff internally, but if it returns a hash map it returns a hash map

I might be asking too dumb of a question. I’m starting to feel like to you, it’s obvious that my function returns a lazy sequence. Is that the case? (if so, I apologize, I was just trying to confirm)

It is very possible to write the same seq returning function with varying degrees of laziness(in how lazy the output is constructed in terms.of the input), but regardless what it returns is still a lazy seq

It’s also no lazier than required

There is a certain amount of essential work

So “yes”? It’s accurate to say this function:

(defn remove-nth [coll index]
  (concat (take index coll) (drop (inc index) coll)))

(Peeling off the first n items)

Your function returns a lazy seq, but isn't a nice lazy seq because it needs to traverse it's input multiple times, but I don't know that you would be able to do any better

Something to keep in mind if you are passing maps in to that is maps are not ordered

Ok. Thanks. I do really appreciate the deeper discussion, I’ve just never delved all that deeply into lazy -vs- realized sequences and I have a lot to catch up on there.

They have a fixed iteration order (in a single program run, a given map will always return a seq with elements in the same order) but that order is not defined

It might change with the next repl?

(I did know it wasn’t defined, I just didn’t know the internal mecahnics)

It generally doesn't because the order ends up being an implementation detail related to how hash codes are calculated

oh ok, got it

But clojure has changed hashing once in the past

array maps exist and are insertion ordered, but you generally should not depend on your maps staying an array map, most operations will promote from an array map to a hash when you have more than 8 items in the map

That implementation detail is for efficiency yes?

Array maps mostly exist (in my opinion) to preserve evaluation order of code in map literals

something like

(defn remove-nth [n coll]
  (letfn [(iter [n coll]
            (when (seq coll)
              (if (zero? n)
                (next coll)
                (lazy-seq
                  (cons (first coll)
                        (remove-nth (dec n) (next coll)))))))]
    (iter n coll)))

ah. this is just doing exactly what the drop and take are doing. except just a single walk. so not saving on “laziness”

Hello, not very scientific but what I do is try with infinite and take some elements : (first (remove-nth (range) 0)) You can also ask the type/class of a result (type (remove-nth (range) 0)) I have no idea if both tricks qualify for an absolute guarantee of lazyness in all cases.

A distinction drawn by some people who are very interested in different kinds of programming languages is between non-strict and lazy. Lazy is taken to mean what is required to produce the final result is evaluated and nothing else. Non-strict is taken to mean that more might be evaluated than strictly what is required.

strict is taken to mean the opposite of lazy everything is evaluated

So you can split quite fine hairs about it, and handling infinite values without blowing up is not enough to show laziness in that sense

Clojure is generally a lot less formal than all that in the terms that get thrown around