iterate issueshttps://gitlab.common-lisp.net/iterate/iterate/-/issues2024-01-03T00:38:00Zhttps://gitlab.common-lisp.net/iterate/iterate/-/issues/24rationale for which symbols are exported2024-01-03T00:38:00ZDon Morrisonrationale for which symbols are exportedIt *looks* as if symbols that introduce clauses, such as `for`, `collect` and `while`, are exported from the `iterate` package; but those used only in the interiors of clauses, such as `from`, `into` and `=`, are not. However there are (...It *looks* as if symbols that introduce clauses, such as `for`, `collect` and `while`, are exported from the `iterate` package; but those used only in the interiors of clauses, such as `from`, `into` and `=`, are not. However there are (at least) two exceptions to this pattern: `in` and `as` are exported, though it looks to me as if they never introduce clauses. Am I missing something? Is there a deliberate reason for this? Is this perhaps a minor bug?https://gitlab.common-lisp.net/iterate/iterate/-/issues/23Some unit tests currently failing2024-01-03T00:01:00ZDon MorrisonSome unit tests currently failingAs a sanity check before trying to make some changes in `iterate` I tried to run the unit tests in a fresh clone of the repo. It looks to me as if there are several failures, though the wording is a bit ambiguous. I ran the tests with `m...As a sanity check before trying to make some changes in `iterate` I tried to run the unit tests in a fresh clone of the repo. It looks to me as if there are several failures, though the wording is a bit ambiguous. I ran the tests with `make test` which I believe ran SBCL 2.4.0 on my Ubuntu 22.04.3 LTS box, using the version of RT that comes for free with SBCL. At the end of its output it appeared to report
6 out of 278 total tests failed: ITERATE.TEST::ALWAYS.FINALLY,
ITERATE.TEST::NEVER.FINALLY, ITERATE.TEST::THEREIS.FINALLY,
ITERATE.TEST::IN-STREAM.2, ITERATE.TEST::BUG/WALK.2,
ITERATE.TEST::BUG/COLLECT-AT-BEGINNING.
No unexpected failures.
DO-ITERATE-TESTS ran successfully.
; in:
; PROGN (FORMAT *ERROR-OUTPUT* "~&Note: These tests generate warnings ~
; involving MACROLET within Iterate~%")
; (ITERATE:MULTIPLYING (ITERATE.TEST::FOO))
;
; caught STYLE-WARNING:
; undefined function: ITERATE:MULTIPLYING
;
; compilation unit finished
; Undefined function:
; ITERATE:MULTIPLYING
; caught 1 ERROR condition
; caught 1 WARNING condition
; caught 1 STYLE-WARNING condition
I'm not quite sure how to interpret that "No unexpected failures." Is that RT-speak for "no failures outside the stuff being tested," or "the above failures are known and expected," or something else?
Anyway, would it have been expected that some tests fail, or is this an indication that there's something screwy in my configuration I need to look into? Are these actual bugs in the version of iterate in the repo that need addressing?https://gitlab.common-lisp.net/iterate/iterate/-/issues/22hashtable or hash-table2023-12-29T22:24:07ZDon Morrisonhashtable or hash-tableOddly iterate spells it "in-hashtable", while Common Lisp itself (as well as Alexandria and Serapeum) spell things involving hash tables as 'hash-table' with a hyphen. I'm guessing I'm not the only one this divergence in spelling trips u...Oddly iterate spells it "in-hashtable", while Common Lisp itself (as well as Alexandria and Serapeum) spell things involving hash tables as 'hash-table' with a hyphen. I'm guessing I'm not the only one this divergence in spelling trips up frequently. It would seem sensible to add "in-hash-table" to iterate, and I think doing so would break no existing code so long as "in-hashtable" also remains as an alternative.
Having briefly discussed this with Robert Goldman by mail, I will set about figuring out how to make this happen, and submit a merge request once it seems to be working, including updating the unit tests and documentation.Don MorrisonDon Morrisonhttps://gitlab.common-lisp.net/iterate/iterate/-/issues/11Iterate's code walker mangles `(if t (progn) ...)`2022-04-28T17:14:58ZPaul RodriguezIterate's code walker mangles `(if t (progn) ...)`It simply omits the progn, inverting the meaning of the condition.
```
(macroexpand '(iter (if t (progn) (+ x y))))
(LET* ()
(BLOCK NIL
(BLOCK #:ITERATE5558
(TAGBODY
(PROGN)
LOOP-TOP-NIL
(PROGN
...It simply omits the progn, inverting the meaning of the condition.
```
(macroexpand '(iter (if t (progn) (+ x y))))
(LET* ()
(BLOCK NIL
(BLOCK #:ITERATE5558
(TAGBODY
(PROGN)
LOOP-TOP-NIL
(PROGN
(IF T
(+ X Y)))
(PROGN)
(GO LOOP-TOP-NIL)
(PROGN))
NIL)))https://gitlab.common-lisp.net/iterate/iterate/-/issues/21Iterate eliminates (progn)s2022-04-28T17:14:56ZLe BigMacIterate eliminates (progn)s```
(iter
(for i below 10)
(progn (progn) (progn (progn)) (progn) (progn) (progn)))
```
macroexpands to
```
(let* ((i nil))
(block nil
(block #:iterate1441
(tagbody
(progn (setq i -1))
loop-top-nil
...```
(iter
(for i below 10)
(progn (progn) (progn (progn)) (progn) (progn) (progn)))
```
macroexpands to
```
(let* ((i nil))
(block nil
(block #:iterate1441
(tagbody
(progn (setq i -1))
loop-top-nil
(progn
(setq i (+ i 1))
(if (>= i 10)
(go loop-end-nil)))
(progn)
(go loop-top-nil)
loop-end-nil
(progn))
nil)))
```
As you can see, all the progns are gone.
This turns out to be problematic for cases such as
https://github.com/phantomics/april/issues/227
```
(iter
(for i below 5)
(collect
(april:april (with (:space emerald-geometry) (:state :unformat-output t))
"(4 2⍴⍳8)[3;]")))
```
as ; is represented as (progn) and the expressions ends up with a different meaning.https://gitlab.common-lisp.net/iterate/iterate/-/issues/20Please cut a new release for QL.2022-02-15T11:31:08ZPhilipp MarekPlease cut a new release for QL.Thanks a lot!Thanks a lot!https://gitlab.common-lisp.net/iterate/iterate/-/issues/19DEFSTRUCT: reading from slots without provided initforms2022-01-31T14:44:18ZMichał Herdaphoe@disroot.orgDEFSTRUCT: reading from slots without provided initformsVia https://twitter.com/RainerJoswig/status/1484711125459550216
https://gitlab.common-lisp.net/iterate/iterate/-/blob/591c15cad8ea0f41bf0314d90adcf4ac5d9078b6/iterate.lisp#L397-428
```lisp
(eval-when (:compile-toplevel :load-toplevel :...Via https://twitter.com/RainerJoswig/status/1484711125459550216
https://gitlab.common-lisp.net/iterate/iterate/-/blob/591c15cad8ea0f41bf0314d90adcf4ac5d9078b6/iterate.lisp#L397-428
```lisp
(eval-when (:compile-toplevel :load-toplevel :execute)
;;; Clause-info structures, which are put in the clause index.
(defstruct clause-info
function
keywords
req-keywords
doc-string
generator?)
;;; Driver-info structures, for information about driver variables--used by
;;; NEXT.
(defstruct driver-info
next-code
generator?
(used nil))
;;; Previous-info structures, used by the PREVIOUS mechanism.
(defstruct previous-info
var
save-info-list
code
(class :step))
(defstruct save-info
save-var
save-vars
iv-ref)
)
```
Reading from a slot for which no default value was provided before that value was set is undefined behavior, and Rainer notes that this bit him on Genera. For instance, `MAKE-PREVIOUS-INFO` is called like `(make-previous-info :var var :class default-class)` which means that the initial values of `CODE` and `SAVE-INFO-LIST` are undefined. Rainer likely ends up with attempts to read from these slots somewhere from within ITERATE, and that invokes UB.
A solution is to provide explicit initialization forms for these.https://gitlab.common-lisp.net/iterate/iterate/-/issues/16Tests failing on clisp2021-12-17T01:42:03ZRobert GoldmanTests failing on clispclisp distributes without ASDF pre-installed, causing the tests to fail there. If anyone wants to fix this, we could take a merge request. I can't be bothered fighting with clisp, personally.clisp distributes without ASDF pre-installed, causing the tests to fail there. If anyone wants to fix this, we could take a merge request. I can't be bothered fighting with clisp, personally.https://gitlab.common-lisp.net/iterate/iterate/-/issues/18Test failures on CMUCL2021-12-08T19:23:32ZRobert GoldmanTest failures on CMUCLOn the `fix-tests` branch, where the tests are fixed to actually check the results on CMUCL, I see multiple test failures:
```
5 unexpected failures: ITERATE.TEST::DSETQ.3,
ITERATE.TEST::FINDING.SUCH-THAT.NEST.2, ITERATE.TEST::UNTIL...On the `fix-tests` branch, where the tests are fixed to actually check the results on CMUCL, I see multiple test failures:
```
5 unexpected failures: ITERATE.TEST::DSETQ.3,
ITERATE.TEST::FINDING.SUCH-THAT.NEST.2, ITERATE.TEST::UNTIL.1,
ITERATE.TEST::COLLECT.1, ITERATE.TEST::BUG/PREVIOUSLY-INITIALLY.1.
```
See https://gitlab.common-lisp.net/rgoldman/iterate/-/jobs/24817 for transcript.https://gitlab.common-lisp.net/iterate/iterate/-/issues/17CI execution on CMUCL is failing with cryptic error message2021-12-08T19:21:04ZRobert GoldmanCI execution on CMUCL is failing with cryptic error messageFor example, see [this transcript](https://gitlab.common-lisp.net/rgoldman/iterate/-/jobs/24811)
```
cmucl -noinit -batch -load test.lisp
WARNING: Couldn't re-execute CMUCL with the proper personality flags(maybe /proc isn't mounted?). ...For example, see [this transcript](https://gitlab.common-lisp.net/rgoldman/iterate/-/jobs/24811)
```
cmucl -noinit -batch -load test.lisp
WARNING: Couldn't re-execute CMUCL with the proper personality flags(maybe /proc isn't mounted?). Trying to continue anyway.
```
This suggests maybe there's something wrong with the docker image?
/cc @etimmonshttps://gitlab.common-lisp.net/iterate/iterate/-/issues/15Tests fail on Allegro's case-sensitive lisp2021-12-08T15:15:58ZRobert GoldmanTests fail on Allegro's case-sensitive lispNot a show-stopper -- tests pass on Allegro's ANSI CL -- but it would be nice to fix this if it's not too much work.Not a show-stopper -- tests pass on Allegro's ANSI CL -- but it would be nice to fix this if it's not too much work.https://gitlab.common-lisp.net/iterate/iterate/-/issues/14Hashtable versus hash-table2021-10-21T18:08:21ZDon MorrisonHashtable versus hash-tableIt seems a shame that iterate spells it "in-hashtable" when Common Lisp spells its type "hash-table", and the various functions "make-hash-table", "hash-table-p", "hash-table-count", etc. It's also spelled "hash-table" in the loop macro....It seems a shame that iterate spells it "in-hashtable" when Common Lisp spells its type "hash-table", and the various functions "make-hash-table", "hash-table-p", "hash-table-count", etc. It's also spelled "hash-table" in the loop macro.
I would suggest adding "in-hash-table" as a synonym for "in-hashtable" and updating the documentation to use that hyphenated form consistent with Common Lisp itself. There's probably no need, though, to ever completely remove the old spelling, just to prefer the consistent one. Leaving it there means no existing code gets broken.
I can't count the number of times I've accidentally typed "in-hash-table" and grumbled when it failed! :-)https://gitlab.common-lisp.net/iterate/iterate/-/issues/5Please make ITERATE easy to use with CL-WHO2021-08-31T07:35:22ZPhilipp MarekPlease make ITERATE easy to use with CL-WHOIt would be great if `ITERATE` could be used together with CL-WHO.
Currently `ITERATE` croaks about the macrolet `CL-WHO:HTM`:
```lisp
(cl-who:with-html-output (*standard-output*)
(iterate (for a in '(1 2 3))
(cl-who:htm
...It would be great if `ITERATE` could be used together with CL-WHO.
Currently `ITERATE` croaks about the macrolet `CL-WHO:HTM`:
```lisp
(cl-who:with-html-output (*standard-output*)
(iterate (for a in '(1 2 3))
(cl-who:htm
(:div (cl-who:str a)))))
; Iterate does not know how to handle the special form (MACROLET ((CL-WHO:HTM ...
; It will not be walked, which means that Iterate clauses inside it will not be seen.
```
As this only applies when _both_ `CL-WHO` and `ITERATE` are loaded, I guess the easiest way of packaging would be to have an `ITERATE+CL-WHO` asdf system that depends on both.
Thanks a lot!https://gitlab.common-lisp.net/iterate/iterate/-/issues/13Downcasing symbol-names FIRST-TIME-P and FIRST-ITERATION-P to keep consistency2021-08-30T18:44:35ZShubhamkar AyareDowncasing symbol-names FIRST-TIME-P and FIRST-ITERATION-P to keep consistencyHi!
The current upcased FIRST-TIME-P and FIRST-ITERATION-P symbols at https://gitlab.common-lisp.net/iterate/iterate/-/blob/master/iterate.lisp#L2422 cause a consistency issue with respect to other symbols, while using Allegro's mlisp v...Hi!
The current upcased FIRST-TIME-P and FIRST-ITERATION-P symbols at https://gitlab.common-lisp.net/iterate/iterate/-/blob/master/iterate.lisp#L2422 cause a consistency issue with respect to other symbols, while using Allegro's mlisp version or with :invert readtable-case or similar.
Would be glad if these get downcased like the others!
Thank you!https://gitlab.common-lisp.net/iterate/iterate/-/issues/12Remove the COUNT collector2021-08-25T23:10:06ZRobert GoldmanRemove the COUNT collectorWe have previously deprecated `COUNT` because it conflicts with a CL built-in (#1). Now we should remove it for the next major release (2.0)We have previously deprecated `COUNT` because it conflicts with a CL built-in (#1). Now we should remove it for the next major release (2.0)2.0 Releasehttps://gitlab.common-lisp.net/iterate/iterate/-/issues/7Summing as a synonym for sum?2021-08-25T23:05:00ZSteveSumming as a synonym for sum?Would anyone be opposed to adding a synonym for sum? Reason: symbol conflict with `sum` is somewhat more likely than `summing`, and we already have similar synonyms, e.g. `generate` and `generating`.Would anyone be opposed to adding a synonym for sum? Reason: symbol conflict with `sum` is somewhat more likely than `summing`, and we already have similar synonyms, e.g. `generate` and `generating`.https://gitlab.common-lisp.net/iterate/iterate/-/issues/10Version ambiguity2021-05-20T18:41:49ZDon MorrisonVersion ambiguityWhile the .asd file calls the latest version in master version 1.5.2, line 126 of iterate.lisp reads
`(defconst version "1.4" "Current version of Iterate")`
This seems just asking for trouble; sure confused me for a few minutes.
I don...While the .asd file calls the latest version in master version 1.5.2, line 126 of iterate.lisp reads
`(defconst version "1.4" "Current version of Iterate")`
This seems just asking for trouble; sure confused me for a few minutes.
I don't think iterate::version is actually used anywhere, so likely the right solution is just to remove that. If it is retained, it might be best to work out some scheme where the .asd file and the .lisp file share a value by one reading the other, or both reading a VERSION file, or something like that.https://gitlab.common-lisp.net/iterate/iterate/-/issues/8free-variables does not work correctly for all lambda-forms2021-03-14T08:26:34ZShubhamkar Ayarefree-variables does not work correctly for all lambda-formsOne example is:
```
(let ((iterate::*env* nil))
(iterate::free-variables
`(lambda (&optional (a 5)) a)))
;=> (A)
```
The expected value is NIL, but `(A)` is returned. The issue seems to be in `free-vars-fspec`, which shouldn't sim...One example is:
```
(let ((iterate::*env* nil))
(iterate::free-variables
`(lambda (&optional (a 5)) a)))
;=> (A)
```
The expected value is NIL, but `(A)` is returned. The issue seems to be in `free-vars-fspec`, which shouldn't simply append `(second fspec)`.https://gitlab.common-lisp.net/iterate/iterate/-/issues/4New SBCL warnings about set-but-not-read variables2020-11-05T11:13:40ZMichał Herdaphoe@disroot.orgNew SBCL warnings about set-but-not-read variablesThanks to @pmarek for the heads-up.
SBCL 2.0.9 introduced warnings about variables which are assigned but never read and about variables which are assigned but ignored. This currently means that e.g.
```lisp
(iterate (for a in '(1 2 3)...Thanks to @pmarek for the heads-up.
SBCL 2.0.9 introduced warnings about variables which are assigned but never read and about variables which are assigned but ignored. This currently means that e.g.
```lisp
(iterate (for a in '(1 2 3)))
```
produces a `A is assigned but never read` style warning, whereas
```lisp
(iterate (for a in '(1 2 3)) (declare (ignore a)))
```
produces a `A is being set even though it was declared to be ignored` style warning.
------------
A possible solution would be to declare all variables bound by Iterate as ignorable, which is what SBCL's LOOP internally does:
```lisp
CL-USER> (macroexpand-1 '(loop for (a b c) in '()))
(BLOCK NIL
(LET ((A NIL) (B NIL) (C NIL) (#:LOOP-LIST-519 'NIL))
(DECLARE (IGNORABLE #:LOOP-LIST-519)
(IGNORABLE C)
(IGNORABLE B)
(IGNORABLE A))
(TAGBODY
(GO SB-LOOP::END-LOOP)
SB-LOOP::NEXT-LOOP
(SB-LOOP::LOOP-DESETQ (A B C) (CAR #:LOOP-LIST-519))
(SB-LOOP::LOOP-DESETQ #:LOOP-LIST-519 (CDR #:LOOP-LIST-519))
(WHEN (ENDP #:LOOP-LIST-519) (GO SB-LOOP::END-LOOP))
(GO SB-LOOP::NEXT-LOOP)
SB-LOOP::END-LOOP)))
T
```https://gitlab.common-lisp.net/iterate/iterate/-/issues/3Nested loops?2020-06-13T18:14:59ZRichard KawalaNested loops?I was wondering if there was a way to do nested loops. I tried:
`(iterate:iterate
(iterate:for i from 1 to 6)
(iterate:for j from 1 to 6)
(iterate:collect (list i j)))`
in the hopes of getting a 6-by-6 matrix, but I got:...I was wondering if there was a way to do nested loops. I tried:
`(iterate:iterate
(iterate:for i from 1 to 6)
(iterate:for j from 1 to 6)
(iterate:collect (list i j)))`
in the hopes of getting a 6-by-6 matrix, but I got:
`((1 1) (2 2) (3 3) (4 4) (5 5) (6 6))`
I didn't see examples of nested loops, and section 2.1 of the doc suggests they aren't supported. Section A.1 talks about better support of nested loops, which suggests they are supported. So I thought I'd ask. Thanks for your time!