2008-08-19
| 14:12 | Chouser | Whee: (take 4 (.iterator [1 2 3 4])) ==> (1 3 4) |
| 14:12 | Chouser | that's quite a thing Stuart found. |
| 14:14 | hoeck | Chouser: strange |
| 14:14 | Chouser | yep |
| 14:14 | Chouser | user=> (def i (.iterator [1 2 3 4])) |
| 14:14 | Chouser | user=> (first i) |
| 14:14 | Chouser | 1 |
| 14:14 | Chouser | user=> (first i) |
| 14:14 | Chouser | 2 |
| 14:17 | hoeck | .. 3,4 it seems (first i) changes the internal state of the iterator |
| 14:18 | kotarak | this is the nature of an iterator, no? |
| 14:19 | hoeck | kotarak: you're right, i have never used them with clojure |
| 14:20 | Chouser | well, it's not clear to me why (first) should cause the iterator to advance, but having an internal mututing state is indeed inherent in Java iterators. |
| 14:20 | kotarak | to get the first value, you have to call next. But next modifies the internal state. |
| 14:21 | Chouser | I'm not sure if preventing (first) from advancing would fix the seq library (so that take, map, filter, etc. would work) or not. |
| 14:21 | Chouser | kotarak: oh, really?? I haven't worked with Java iterators much. There's not a "current value" accessor? |
| 14:21 | kotarak | Chouser: No. Only next and hasNext. |
| 14:22 | kotarak | Who would want to get a value without advancing the state? (<- You can always surprise an (software) engineer...) |
| 14:22 | Chouser | ugh. So really, (first) and (rest) shouldn't work on Java iterators, because they just can't behave correctly. |
| 14:26 | Chouser | it looks like first and rest automatically create a seq from their arg (if it's not already an ISeq) |
| 14:27 | Chouser | Thes works once for an iterator (creating an IteratorSeq), but then the call to first advances the underlying iterator. |
| 14:28 | Chouser | so the next call to first creates another new IteratorSeq and advances it again. |
| 19:26 | JamesIry | first and rest can work on Iterable, not Iterator |