I still don’t get it. Could you help me by trying to rewrite the map over stream block (the actual application of my request for help) in such way that this:
BTW (for the sake of completeness): the stream blocks are from Streams library rel. 2 (under development), not to be combined with blocks from Streams library rel. 1 (currently official).
@dardoro, are you reading this? (if you can't or won't help me that's OK, just let me know pls)
I just remembered something previously said here, if streams are calculated from a seed (supposedly), what happens if a stream that's supposed to be only 10 items long gets bigger?
That's actually a good question, as the answer depends on the character of the stream. If the stream is clearly finite, item 12 of a 10-item stream is the same as that of a 10-item list:
A clearly finite stream, of 10 items.
terminate streameffectively makes a finite stream from the item where the condition applies.
However some streams seem infinite but are actually finite. A somewhat exaggerated example:
This stream has only 10 items, but the algorithm isn't aware of that, as it may test the condition for each candidate item, but doesn´t "understand" what the condition implies for the stream as a whole.
This sort of inconspiciously finite stream will be searched forever for a next item.
Yeah, I guess we should clarify in the documentation that "finite stream" means a stream in which THE EMPTY STREAM appears as the tail of something, not a stream that can be shown to have only finitely many reachable items but doesn't have an explicit end.
Great. Let me know when you're done; I really want to get this into v10. (Because you want the blocks ordered in a specific way, and I agree, the PR has to be against the dev version, not against the production version.)
Ugh, I don't know. I never know until I start writing what a manual section will look like. Bunches of other libraries need better documentation, too, notably the bar chart ones, but also things I have no idea about, such as MQTT. I could have sworn I'd written a FAQ here about streams, but apparently not. So I'll probably start with this post in writing the manual section.
Sorry, "pull request." That's how you propose a change to a Git repository. ("Git" is the software that manages updating projects; "Github" is a particular cloud hosting service for Git repositories.)
I’m done. All that remains to be changed now (IMO) is removing the ticks from the names of refactored functions (I put them there to prevent any mix-ups during development), and export the blocks.
Are you (bh) going to prepare the PR? Will there be a possibility to align the order if the blocks?
I’m sorry we can’t have automatic ring variables, or upvars, for now: too buggy. I had hoped @dardoro was onto a solution, but I couldn’t integrate his suggestions so as to get it all to work flawlessly. Well, perhaps in a future release.
A summary of the changes from v1 to v2:
The data structure was reduced to the essence. Basic blocks tail of stream and in front of stream were changed accordingly.
Two new basic blocks were added - is stream empty? and the empty stream - making all but 5 blocks fully independent of the stream data structure.
The show stream block was replaced by list .. items of stream, and improved so as to stop searching for additional items as soon as the requested number has been produced.
Fourteen other blocks were added, of which interleave and flatmap will prove most valuable, I expect (some others, like map over keep from map, are nice-to-haves).
Help texts were overhauled, and demos added in each block editor.
Groovy. So far this week I've made three "I'll do this tomorrow" promises and failed at all of them, so I'm reluctant to make another, but I'll get to this soon!
You could actually open the project in development (i.e. Snap! v.10), rearrange blocks within the palette, save the result, and reopen it in the regular version. The only thing that won’t work is space above.
Or perhaps (IDK) that’s what you intended in the first place.