I was using the streams library when I noticed an issue in this block:
I have now introduced a number of suggestions to reduce clutter and fix bugs, which can all be found here:
https://snap.berkeley.edu/snap/snap.html#present:Username=mark4sisb&ProjectName=Streams%20Fixes
@qw23 Do you approve of these changes? I'm not sure that the call to SUBSTITUTE VARS in GENERATE STREAM was meant to solve a problem about upvars, as the comments in @mark4sisb's version seem to suggest, but rather about free references to the dynamic environment.
What does "free references to the dynamic environment" mean?
In any case, the way the library is working currently is not right:
I can try to fix the SUBSTITUTE VARS block, but given that I don't know what it is supposed to accomplish I cannot guarantee that I wouldn't compromise that goal. Here is what I have got:
As you can see, it still fails on the last example in a very confusing (to the user) way. In any case, I certainly don't want these changes to break anything that works currently.
As it turns out, this is the reason for the introduction of substitute vars:
The issue was similar to the one I was encountering, and thus my original solution works. Mostly. I recreated the scenario:
The fix is simple, and I will update the project:
The use of ARG inside the ring is a free reference because ARG isn't a parameter of the ring. If the ring looked like
that would be a bound reference.
But, alas, my example doesn't work in the vanilla streams library anyway:
As for "dynamic environment," that means the variables of the procedure that called you, rather than the variables of the procedure inside which you were created. The GENERATE STREAM procedure can't ordinarily make reference to the variables of FOO (namely ARG), but this should work anyway, because the ringed function carries with it the environment (the name-value bindings) of the procedure in which the ring is created. Unfortunately, GENERATE STREAM doesn't actually call that ringed function; it uses metaprogramming tools to generate a new, separate ring that doesn't carry FOO's environment. Aargh. I hate computers.
First of all I'd like to express my appreciation for @mark4sisb taking the trouble of reviewing the Streams library! That'll surely help to improve it.
I noticed they - is this form of address even legal in the USA nowadays? Will UC Berkeley be targeted by Mr.T. now? 
- are proposing some cosmetic changes, too - such as hiding auxiliary blocks (i.e. blocks imported from a different library); I / we should've done that in the 1st place, so thx4 the suggestion!
I'll look in to the substantative proposals (including any additionals) sometime later this week.
Keep it up, please!
Similarly, my version of the block uses metaprogramming to introduce a ringed parameter for use as the "#" variable. However, I include an ([ V] of (function)) block to restore the original context (the dynamic environment) and allow the use of free references.
At least they're consistent, right?
I see the one that handles the # variable, but nothing that imports the variables of the caller. But it seems to work anyway. ¯\_(ツ)_/¯
I mostly agree. I was reading some posts about trying to minimize the amounts of auxiliary blocks in the streams library, and this would solve the problem well.
However, I'm not so sure about this for one reason:
you're a beginner to snap but with some experience in other programming languages. you import metaprogramming to use a blockify @list ::lists reporter block, then you open the streams library to do some more lists work. you are wondering where the (blockify @list :: lists block is, because it's gone from the pallete but still in other custom blocks you made. Of course, this was because the streams blockify block had a helper="true" (hidden block) xml tag and replaced the other. Because streams has a rather large amount of auxiliary blocks, this is more of a problem with this library than many others.
offtopic
fortunately, just because some of the government doesn't recognize it, doesn't mean they are disallowed from saying it, and we are certainly not. freedom of speech :)
although maybe at some point that'll be gone too. :(
Yes, I agree, this is a weakness. Ideally, if you load a library with a hidden block, and the same block (not just the same title) is already in the project unhidden, it should stay unhidden. It's not clear to me what should happen if the project has a different block with the same title; this is why they felt the need to add packages (basically, library-local scope analogous to sprite-local) to Scheme. I guess we should think about doing that When Things Slow Down™.
but what counts as a library? what if someone wanted to make their own version of the streams library, would that count?
You learn something every day.... 
A package feature lets users declare packages; a package is a collection of procedures. Basically all names inside the package are hidden with respect to code outside the package, except for the procedures that the package chooses to export explicitly. So it's a little like making an object class, except that there are no instances, just the methods. In a text language you put the procedure definitions between begin-package and end-package syntactic markers; if we implemented packages in Snap! it'd probably be by explicitly declaring each procedure definition into the package with a dropdown of package names. Unless we wanted to be radical about it and implicitly treat each user-defined block category as a package.
I just updated the project with a couple more fixed for the generate stream block:
Firstly, it turned out that I was losing the parameters of the ring in the generate stream block, making things like this fail:
Moreover, because the script was being changed metaprogrammatically, there was no way to monitor the progress inside the ring using visible stepping. I have simplified my implementation so that both of these problems are fixed.
Where did you publish your project's latest version? 'cause if it is where the link in your original post leads, the generate stream block appears to not always work as intended, e.g. (comparing the library version with yours):
vs. 
As for your other proposed changes, and questions:
- Hiding external library blocks: perhaps the way forward would be to rename those blocks and subsequently hide them, so as to prevent any interference with other libraries;
- Regarding
the empty stream: replacing a global variable with a block variable is a good suggestion, I suppose; - You appear to wage a vendetta against
let- why? - Your proposed version of
(#) for each (item) in stream (stream) (action)appears to be superior to the one currently within the library; - Within one comment you’re asking: "What is the point of these blocks - how do they maintain compatibility? They just call their V2 equivalent." - true, and intended: thus any code developed on top of v1 of the library will still work with v2, since the original (v1) block is still offered by library v2, with slightly different underlying code.
Whoops. Should've tested that before updating the project (I was going to test it more thoroughly this morning after a good night's rest). I've published a fix that I have tested thoroughly. Unfortunately, this means that visible stepping will not work.
Like I said in the project, it is my understanding that let blocks are significantly slower. I also find that the zebra colouring of the upvars annoys me, but I would not force anyone else to conform to my aesthetic tastes. My removal of them is mostly a function of their speed - feel free to not implement this part of my suggestions.
Oh, I see. You can take a project from V1, import the V2 library and then all the streams blocks will be overwritten. I thought that, because they were a different category, this would not be the case.
the reason the blocks are still overwritten is because the old and new blocks have the same spec (same label and inputs) as each other. Unfortunately, the category does not matter.
Where did you publish it? (I tried the link within your OP, to no avail)
BTW please try this test case:
(
stream A promises positive squares, stream B will produce Fibonacci numbers)
It depends. The version of let as used within the Streams library is much faster than the one from the Declare & Initialize Script Variables library. It is still somewhat slower than script variables + set, though, but - in my opinion - also more elegant. Within the Streams library, repetitive use has been avoided, so it won’t really influence execution times. That being said, whether to use let is mostly a matter of taste - I guess we agree on that 
.
Let me know when you guys have reached an agreement on v2.1...
Sorry about that. I (could've sworn I) clicked save, but apparently the project didn't update. I'm reprogramming my fix now.
Edit: Maybe I accidentally imported an older script pic when I was looking at tests and thereby got an old definition.
Edit 2: I've got it up and running, but I won't publish until I've guaranteed that there are no more problems/mistakes:
Edit 3: Project updated. You can see my tests on the right.