Streams library 2.0 development, part 1

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:

… will still work (= report the same result) if the spoiler is engaged?

Thx in advance!

Link to the project (including your blocks, not integrated yet).

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? :wink: (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?

I don't understand your question. Could you elaborate?

I'm curious what would happen if you got the 12th item of a stream that was only supposed to be ten items long.

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:

Streams extended script pic (40)
A clearly finite stream, of 10 items.

Streams extended script pic (42)
terminate stream effectively makes a finite stream from the item where the condition applies.

However some streams seem infinite but are actually finite. A somewhat exaggerated example:

Streams extended script pic (43)
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.

Mmm, I wonder how. The point is already made in the help text of keep … stream, and in terminate stream ‘s demos.

Really the Reference Manual should say much more than it does about streams, instead of just telling people to read SICP. When Things Slow Down™.

I could write something if you like. Do you have an example of what the section should look like? Any other specific points you think should be made?

I'm currently making some technical code updates, mostly speeding up.

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.)

What’s “the PR”?

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:

  1. The data structure was reduced to the essence. Basic blocks tail of stream and in front of stream were changed accordingly.
  2. 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.
  3. 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.
  4. 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).
  5. Help texts were overhauled, and demos added in each block editor.

Yeah, my plan is to make the PR against the dev version (which allows positioning) rather than against the regular one (which doesn't, yet).

OK, I will not touch the project any more, unless at your (bh) request.

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.

Yeah, that's the idea, except for the "reopen" part. This will be a new library in v10, like Metaprogramming, except that it replaces an old library.