-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[REGRESSION] iterator composition doesn't work, preventing lazy map/filter/etc libraries #8188
Comments
I doubt |
well, knowing what commit broke this would definitely help (especially for ppl not familiar with compiler internals), as it narrows down the search to just a few lines of code I would consider this a high priority bug as it prevents functional programming based on map/filter/reduce/etc (and breaks a bunch of libraries that used to work, albeit a long time ago) |
#3837 I agreed with you. Duplicate bug, closing. |
@timotheecour I suggest you use zero-functional which should cover most of your needs with iterators chaining and be significantly faster than closure iterators and also works today (inline iterator chaining is also broken even though it should work according to manual #4516). One limitation is that you cannot do an infinite iterator but you can initialise from a closure iterator for that. |
@mratsim it's not so much infinite iterator that's not working but more generally iterators from which we don't know the size ahead of time (analog of D's Input range, see https://dlang.org/phobos/std_range_primitives.html). These are fundamental for efficient stream processing (as opposed to batch processing), eg, processing stdin line by line and applying map/filter etc. /cc @alehander42 |
@alehander42 ^ |
@timotheecour that should be possible, it would be easy if one already has a defined byLine zero-functional primitive, I think something like if there is not something like byLine, there is already a nice zf_inline dsl to create a custom one by @michael72 |
I don't quite understand the deal?! proc test() =
readFile(fileName).splitLines -->> filter("error" in it) --> createIter(s)
for line in s():
echo(line) or lines(stdin) --> map(it.toUpper()) --> createIter(s)
... should work?! |
fixed in c554c2a |
Here's a simplified scenario.
It's a major blocker for any kind of lazy map/filter library, such as https://github.com/def-/nim-iterutils/blob/53f4a30e57f01cd8cf9d5b1dd22053eac82b25f2/src/iterutils.nim#L303 "TODO: Currently fail" where it shows map/filter etc cannot be composed.
this prints "done"
it should print 0 1 2 3 4 5 done
EDIT this is a regression, I just verified this worked in 0.9.4 (which was nimrod)
NOTE: I also verified https://github.com/def-/nim-iterutils used to work with 0.9.4:
NOTE: to build 0.9.4, unfortunately choosenim didn't work, see but I posted in dom96/choosenim#66 (I show there how I built 0.9.4 , not sure if there's a simpler way)
EDIT
I just tried with v0.13.0, that version already has the regression.
Not sure how to build nim for versions between v0.9.4 and v0.13.0 because https://github.com/nim-lang/csources.git doesn't have any git tag between these and
./bin/nimrod c koch
fails for csources.git:v0.9.4 with Nim:v0.12.0EDIT fixed in c554c2a
The text was updated successfully, but these errors were encountered: