A couple of years ago I finally started to understand the Waters series facility [1], which was offered as an alternative to Loop. It's a bit finicky, and the error messages are often mystifying, but I have come to quite like it for some more complicated looping situations. The thing that finally made it accessible to me was a blog post by Joe Marshall, Series tips and tricks [2]
Ironically enough, once my use of it advanced enough, I found myself writing producing forms which are just a restricted form of Loop invocation - Series turns out to compile down to Loop. It's just that I (and others, apparently) find Series expressions more pleasant to deal with than Loop expressions.
I shared the urge to avoid loop until I read Pascal Costanza's Highly Opinionated Guide to Lisp[1]
>> Seemingly, the intended way to use the LOOP facility is to just "guess" a way to express an iteration and see if it works. If it doesn't you can either look up the specifics ...
Since then, I do just guess at the syntax and it strangely does what I want most of the time.
It seems that a library like this has a lot to prove because a) it doesn't provide a new capability, b) it adds a project dependency, and c) creates yet another way to do a standard task. If you really don't like the loop macro, you probably don't need much persuading, but I would have liked to have seen more discussion on the these trade-offs.
The grammar for what's accepted by Loop is well specified, but the results also read very clearly. Once you learn a few of them, you start to understand how the rest would be written and can guess, but the design is not that you would guess.
Funny. I'm pretty sure I failed a technical interview many years ago due to the whiteboard exercise in which I used LOOP pseudocode to solve the problem. They weren't Lispers and assumed the code wouldn't work, but I was sure it did (I couldn't explain why though, at the time, as they made me doubt my solution).
Either way I think they were looking for a recursive solution. Oh well, they still invited me to lunch, though.
Loop works well, is widely used, also available in Emacs Lisp and comes with zero dependencies. For these reasons, I don't see this gaining much traction.
Anecdote: In almost 20 years of CL usage, I've never needed an extensible iteration construct. I also find 'loop' a lot more readable than 'iterate' [1], another fad that has come and gone.
TIL that there is a whole package for “Common Lisp Emulation”[1] in Emacs that adds functions and control structures from CL “to make Emacs Lisp programming significantly more convenient”. Never developed a package for Emacs myself, but I feel like this can be of great help if I ever wanted to.
I know that there are projects like Lem[2] that try to build some kind of editor (Emacs-like, I guess) on top of CL, which made me wonder if we would have a CL-based Emacs today if it would have been standardized by the time and if this would have been a better choice than creating a custom dialect.
In what sense is iterate a fad that was gone? I see 1161 systems in Quicklisp (out of 5499 total) that transitively depend on iterate; so about a fifth of the open-source ecosystem.
Transitive dependencies are a poor indicator of actual utilization. How many direct dependencies are there?
For what it's worth, I quit using it since it broke if you ever used the CL function `count` inside an iterate construct. Reportedly it was fixed, but it's still failing to work correctly using the Quicklisp version (just installed CL on and setup QL since it's a new laptop, so it shouldn't be pulling an old version). It was fun for a while, but having to remember "Oh yeah, don't use count" every time I reached for it for something natural was annoying and not worth bothering with.
I find iterate much better on the other hand. Especially the part where I don't have to use :do to switch back to CL syntax and I can use the usual nested if else without having to remember the :end/:then stuff.
* Eschewing collection is a mistake in my opinion. Yes, you can do your own with (let ((ret)) (for ... (push it ret)) (nreverse ret)), but it'll be verbose.
As other said, it's a very Scheme-y vision of looping, which has simplicity/purity/explicitness advantages but lacks in pragmatism. Personally, I firmly stay in the iterate team, even with its issues.
I don't lisp, but `in-iterators` is badly named unless there's precedent elsewhere in the lisp community. I initially expected it to implement (Cartesian) `product` rather than what's usually called `chain` (though admittedly the former is less useful in a language where `for*` is directly possible). Note that `product` really needs optimizations depending on whether its inner iterators can be trusted to be repeatable or not.
I also find it a bit fragile for iterator implementations to use 2 functions, rather than a single function returning `value | unique-end-of-iterator-sentinel` (there are at least 3 obvious ways to lay this out such that there are no values an iterator cannot produce).
Readit News
Ironically enough, once my use of it advanced enough, I found myself writing producing forms which are just a restricted form of Loop invocation - Series turns out to compile down to Loop. It's just that I (and others, apparently) find Series expressions more pleasant to deal with than Loop expressions.
[1] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node347.html#...
[2] http://funcall.blogspot.com/2022/07/series-tips-and-tricks.h...
>> Seemingly, the intended way to use the LOOP facility is to just "guess" a way to express an iteration and see if it works. If it doesn't you can either look up the specifics ...
Since then, I do just guess at the syntax and it strangely does what I want most of the time.
It seems that a library like this has a lot to prove because a) it doesn't provide a new capability, b) it adds a project dependency, and c) creates yet another way to do a standard task. If you really don't like the loop macro, you probably don't need much persuading, but I would have liked to have seen more discussion on the these trade-offs.
[1] http://www.p-cos.net/lisp/guide-v1.html
Only css is done this way... but not even intentionally
https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node235.html
The grammar for what's accepted by Loop is well specified, but the results also read very clearly. Once you learn a few of them, you start to understand how the rest would be written and can guess, but the design is not that you would guess.
Perl was famously that way. It's great for the initial write but not so good for maintenance.
Either way I think they were looking for a recursive solution. Oh well, they still invited me to lunch, though.
Anecdote: In almost 20 years of CL usage, I've never needed an extensible iteration construct. I also find 'loop' a lot more readable than 'iterate' [1], another fad that has come and gone.
[1] https://iterate.common-lisp.dev
I know that there are projects like Lem[2] that try to build some kind of editor (Emacs-like, I guess) on top of CL, which made me wonder if we would have a CL-based Emacs today if it would have been standardized by the time and if this would have been a better choice than creating a custom dialect.
[1]: https://www.gnu.org/software/emacs/manual/html_node/cl/ (C-h R "cl" in Emacs)
[2]: https://lem-project.github.io
For what it's worth, I quit using it since it broke if you ever used the CL function `count` inside an iterate construct. Reportedly it was fixed, but it's still failing to work correctly using the Quicklisp version (just installed CL on and setup QL since it's a new laptop, so it shouldn't be pulling an old version). It was fun for a while, but having to remember "Oh yeah, don't use count" every time I reached for it for something natural was annoying and not worth bothering with.
> iteration and value accumulation are orthogonal problems which should be solved by orthogonal constructs
This is also covered to an extent by "Why Functional Programming Matters" in the discussion of laziness: https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.p...
For a direct comparison of combining this syntax with "accumulation" into a lazy sequence, see Clojure's `for` macro:
https://clojuredocs.org/clojure.core/for
* Syntactic sugar for nested loops is welcome!
* I would have preferred a comparison with https://github.com/Shinmera/for/, as it's nearer in concept than loop/iterate.
* Eschewing collection is a mistake in my opinion. Yes, you can do your own with (let ((ret)) (for ... (push it ret)) (nreverse ret)), but it'll be verbose.
As other said, it's a very Scheme-y vision of looping, which has simplicity/purity/explicitness advantages but lacks in pragmatism. Personally, I firmly stay in the iterate team, even with its issues.
I also find it a bit fragile for iterator implementations to use 2 functions, rather than a single function returning `value | unique-end-of-iterator-sentinel` (there are at least 3 obvious ways to lay this out such that there are no values an iterator cannot produce).