The most famous and popular language has just one letter - C and C++, So I suggest X

Oh this is a bit isn't it

I am serious by the way , just hypothetically

I'll pretend that I didn't see that message and will keep on thinking that it's a bit. :)

Lisp++?

I will fork clojure and call it X

Ljsp

> no mature programming language has been renamed before And this is also wrong. Perl 6 -> Raku immediately comes to mind, and I'm certain there were others that I can't recall right now.

LiveScript->JavaScript->ECMAScript

javalisp2023

Scheme -> Racket -> Rhombus?

JavaScript -> ECMAScript?

Oh well, if it must happen... Is the name "Hammock" already taken?

although sadly it's not there anymore, someone once created a PR against clojure/clojure renaming every single occurrence of "Clojure" with "Lava" (lisp on java)

It kind of depends on what you mean by "lazy". There are multiple options with different trade-offs: • lazy seqs via the 3+ arity sequence functions like filter, map, etc • lazy seqs via sequence • laziness via eduction • A non-lazy approach is for fetch-all-the-docs! to accept a transducer • and more!

Laziness is super! Embrace it when its characteristics serve your purposes.

@U7RJTCH6J I don't think transducers would work, as I want to use it as shown in the example above. As for the multiple kinds of lazyness, I'm pretty unfamiliar with them. Usually I just have to mentally keep track of what is lazy and what is not. 😕

Transducers can help here:

(let [[doc1 doc2] (fetch-all-the-docs! (take 2))]
  ...)

Personally, I usually tend to prefer the option that iteration takes which is to return a seqable/reducible .

the destructuring itself is not necessarily lazy, it uses nth

so it kind of depends here what fetch-all-the-docs! does. I'm not sure what your goal here actually is. destructuring is going to force the first two elements to exist. are you worried about realizing more than two items?

Yes. I don't want to fetch 10k+ items when I really just need 2 or 3. It looked like lazyness was a perfect fit for this.

Destructuring by itself won’t have this issue

I'm not worried that destructuring will cause any problem, I'm simply interested in a way where I can use destructuring without repeating myself in the function. For example, DB APIs will often have a :limit field.

(let [[d1 d2] (fetch ... :limit 2))

Well, with the caveat that Clojure's laziness is 32 element at a time, so you'd be fetching in chunks. The alternatives are iterator and generators, and the likes.

The article describes multiple reasons why a lazy (fetch-all-the-docs!) can be a bad idea: • Does it open an external resource? If so, do you properly close it in the face of deferred execution? • Does it fetch documents 1by1 or 32 at a time? Is that OK for you? • Have you established proper error-handling constructs either around let or inside fetch-all-the-docs! (but in the proper places)?

> It looked like lazyness was a perfect fit for this. > In a perfect world, yes, it is the most elegant. But when you start to look at practical side, having :limit n might in the end be a better options, all things considered. Either that, or other approaches suggested above (accepting a transducer, returning an eduction instead of a lazy sequence). Note that the eduction approach might still have the same problems with resource management and error handling.