Streams library 2.0 development, part 1

[qw23]

@bh

@qw23

but empty slots may be safer in the end:

I'm not sure what you mean. I don't see any empty slots in your example.

Yeah, my example was unclear. What I meant is to not use upvars but tell users instead that the block (e.g. exec, a simple example block I made up) will supply e.g. value and index as parameters to the callback function:

Knowing that, the user can decide how they will define the callback function. The list below contains 5 examples:

• the 1st example is with empty slots;
• the 2nd is equivalent to the first but with (optional) user-created parameter names;
• in the 3rd example the user must use parameter names, as the callback function will otherwise use the wrong order (and the result will be like examples 1 and 2);
• it's about the same with example 4; if no parameters are specified the result will be like ...
• example 5.

@bh

@qw23

A number in a Boolean (unevaluated) slot is interpreted as a reporter of that number, so it must be call-ed; there’s no use for other input at calling time, as all of the required information will already be there.

But can't the number be provided by an enclosing function?

What I wanted to achieve is that a user could simply enter a number instead of a predicate; and that the number would then be interpreted as [ _ > number ]. It was actually an input parameter slot of type Any (unevaluated) - not Boolean (unevaluated) as the latter won't accept numbers to be kbd-entered. Perhaps the next script / result pic will clarify my point:

Since I'm probably not going to be using this trick any more, it doesn't really matter.

@bh

No, I'm suggesting deleting all the asterisks and leaving the code otherwise unchanged.

Do you mean this then?

I also tried other options, such as an external Helper block, and an iterative version - but differences in runtime are IMO negligable (and not systematic):

I don't know of any differences of memory use - wouldn't know how to measure these.

Preparations for library distribution

I prepared three sets of blocks:

1. a comprehensive set of library blocks to be distributed anytime you like
2. a set of blocks that need some more testing
3. a set of blocks under development

I put a warning message about the slight change of data structure in the help text of tail of stream, and referred to this text from the latest versions of the pre-existing blocks (= currently included in the Streams library). They may be recognized by a check mark ( ) as first character of their labels. The help text of tail of stream must be updated with the new version id (or distribution date) of the library, IMO.

Did you reconsider the categorization thing? Since streams are actually a separate data type (if stream blocks look almost the same as list blocks, it will be easier for users to mix them up, especially in front of, map and keep, perhaps uniques of) (and is empty? - not such a big deal), and we have plenty of blocks (24 27, added combine a.o.) which would otherwise overcrowd the already overcrowded Variables / Lists / Other palette, I really think stream blocks should be a separate category, with a distinctive colour, just like e.g. TuneScope and SciSnap!. What do you think?

Recently discovered issue (at least: new to me)

I tried: , and found the process wouldn't terminate.
Then I tried the current library's: , which produced the same effect.
I guess there is no solution for this, a stream must be evaluated once to find out if there are any elements in it. I suppose you must have been aware of this. Any thoughts?

I made a remark in the Help text of is stream empty?.

Another question

Do you think it would be useful to offer both value and index to all map reporters and keep predicates? Like I did with the terminate block (you won't like the layout - I'm looking for a better name of the block, where it makes sense that the stream input is at the back: once…?). It may not always be useful, but at least it would be more consistent with similar list operations. The only downside I can think of is that existing user code may have used more than one empty slot for value, like in:
.

Repairing show stream

You may not be going to believe this … I fixed show stream. What was even wrong with it? Well, it kept searching for one more item after all of the requested items were found. Unnecessary and even potentially harmful! E.g.:

will not terminate. This is caused by the fact that the input parameter stream is evaluated even if number = 0. I repaired this by making stream an unevaluated input, and testing for number = 0 before evaluating:

Thus:

(in my library version show stream is a compatibility block, effectively just calling list items from stream)

Meanwhile I discovered a downside to my improved block: monitor (log↑) stream (s) doesn’t work any more, i.e. I can’t read the upvar in a next line of code. Probably because the stream chain is now unevaluated. Well, never mind, I wasn’t too enthusiastic about upvars in the context of streams anyway. I re-engineered monitor ….

Something else I encountered (is it a bug?)

I made a copy of an existing custom block (show stream), and changed just the type of 1 inout parameter (from List to Any (unevaluated)). I could now save the new block without a trailing (2) in its label. so it was apparently recognized as different from the original. However, I could not edit both blocks at the same time: once I opened a second block in the editor, the first one disappeared, and vice versa.