It's equal to ω, but ω+1 is greater than ω. It is $$\omega\cup\lbrace\omega\rbrace$$ in von Neumann notation.
Right. When I first complained about the name, I wasn't really thinking streamishly. I went from "You're only actually going to look at the first 10 [or whatever] items" to "the stream will only have the first 10 items." Of course the stream contains the entire list (but sorted), even if the whole reason to sort into a stream rather than a list is that you're only going to look at a few items. So its name should reflect that. SORTED STREAM FROM ANY LIST? Its help screen should explain that the reason for the block is that if you only want the first few items it takes 𝜽(n) time instead of 𝜽(n log n). As well as pointing out that the input is (necessarily!) finite and so the output is too. I must be really tired; I just noticed that I wrote "it's" two sentences ago and fixed it, before posting at least. :~(
Okay, maybe to implement this you'd have to do macrology on the ITEM OF STREAM block... or maybe not... but talking about items #-1, #-2, etc., is counting backward from this point in the stream. I'm envisioning that you wouldn't allow ITEM 1 OF, only #-relative indices down to a certain point. Or maybe you would allow down to 1, but it'd be way more efficient if you didn't use small indices, because you'd preparse the expression, notice if the user is asking for small indices, and in that case keep a pointer to the entire input stream. But if only #-relative indices, you can internally keep a bounded history list that ITEM could use. No, you would have to do macrology on ITEM, because it wouldn't evaluate its second input, because if it's the entire input stream, you don't want ITEM to be forcing keeping the entire stream (so far) in memory. You'd convert ITEM #+offset OF (original stream) to ITEM (offset) OF (remaining stream) except that if offset is negative you'd call ITEM |offset| OF (history).
The goal here is that users should think the entire stream is available, even though some items really aren't, and that requires intercepting user references to the original stream.
I looked at your latest version. Your HIDDEN BLOCKS block assumes the existence of a sprite named "Auxiliary blocks." You can't do that in a library! I think if you want to advertise them, you should just have an UNHIDE HIDDEN BLOCKS block that does that, along with a long help screen explaining them all.
I thought we had agreed to unhide ITEM OF STREAM and SHOW STREAM (because they're in SICP).
I’m making that sorted stream from unsorted list (), and will point out both of these topics in the help text. Do you now think it's interesting enough as a demonstration of what streams may be used for? (like sieve)
You must be getting tired indeed 
… this is too fuzzy IMO - plus, I wouldn’t want to introduce any macrologic complexity praeter necessitatem. For now (and awaiting response on the upvars issue) I’ll keep it simple, i.e. item 1/2/… of hindsight (it would have been easier if Snap! offered the possibility to address a list with a negative item number if you can understand streams, and higher-order-functions, I’m sure you can understand a stack, which hindsight essentially is).
I was pottering around a bit, really. Not sure if I’ll want to keep any hidden blocks at all. May try the targeted unhide feature, though.
I’ll restore item of stream though I’m not sure myself of it being useful. I consider show stream a compatibility block, to be kept available in order to facilitate older code, but not necessarily in the palette - it is functionally equivalent to list () items of stream, which is easier to use.
I'm looking forward to the muggles guide to all this 
Would you be proofreader?
Okay, now I'm confused. Take the natural numbers, or any other sequence whose natural ordering has a finite left edge but no right edge. Now add something at the left, e.g., -1. What results still has the desired property that any item is reachable in a finite number of steps. On the other hand, if you add something on the right, e.g., ℵ₀, (as one item, not appended), it's not reachable in a finite number of steps. So adding on the right should be the problematic case, the one whose ordinality is > ω. What am I missing?
Same thing happens with ω+(ω^2).
ω+(ω x2)=(ω x3) but ω^2 is the supremum of ordinals α->ω+α
Just like ω = sup{α->1+α}
It's the minimum ordinal such that doing another of the same mapping that the ordinal has already been through an infinite amount of times won't change the value of the ordinal, unless you do it with it's successor.
Yes, fine, I guess it's comparable to sieve as an illustration of what streams are good for, although (because the data set is finite) it doesn't have nearly the wow factor as the stream of all the primes. :~)
Okay.
Not if you're studying SICP, which is very likely if you're using streams in Snap!!
Yah me too. I think the target audience can't quite be complete beginners, if that's what a "muggle" is in this context. I would assume total familiarity with lists, including the head/tail style of recursion on lists as well as the use of HOFs. I think I could write something with that starting place.
Okay, I take back adding ℵ₀ at the end. Just add "Fred" at the end. Anything atomic and finite. Bringing ω+(ω^2) into it feels much too massive.
I studied transfinite cardinals in high school (on my own, not in a class), but it wasn't until much later that I even knew there was such a thing as ordinals. I guess I should sit down with a book and really learn all this.
I've only understood about 1% about what your going on about so I don't think I'd be much use
… actually sounds like you fit the profile 
@bh and @polymations Please don't derail this thread with the maths stuff - it's hard enough keeping track as it is
We were already derailed before, as this topic is about logic programming originally.
It will get back on track if when @bh moves posts 88+ to a separate topic, called "Streams library maintenance" or something.
I decided to adopt bh's witty proposal of map over keep from map over stream (without the fancy colours), and replace my original map over keep from stream (a.k.a. Python list comprehension arranged for streams) with it. It's almost as fast even for simple cases.
I dropped some of my own "optimizations" such as variadic stream-merge and variadic stream-interleave, they don't add much value as it turns out.
For now I'm done with developing, I think - the only kind of feature I would like to add is for reporters and predicates to be able to use index and stream history according to the Snap! style guide (?). For that I'll be awaiting response from bh a/o jens about ring variables a/o upvars (which appear not to work as I want them to, when used in stream blocks). " Don't hold your breath" is an answer, too - in that case I propose to publish the library like this.
I welcome anyone's remarks on:
- the set of blocks
- hat blocks
- definitions
- help text
- demo examples
Thx in advance!
Made a simple script that worked in the way I thought it should so quite pleased with myself
but this block just looks insane!
Wow, you just wrote your first stream program!
A variation is:
(I thought a list of 100 would take up too much space here )
BTW I renamed one of the project’s sprites after you!
Now, do you think you could create a stream of squares?
(not necessarily with bh’s over-the-top map/keep/map block, though it’s definitely an option)
It's not my first stream rodeo - I've used the existing library before
Aah- that one is Brian's fault then!
You might consider reimplementing this in your stream library:
Thx4 your comment.
Would you be more specific?
An example generator of positive and negative integers, and one of fractions, perhaps?
Or are you thinking of robots moving according to coordinates from a stream?
Or ... ?
I was thinking at the level of streams - not robots and birds.
An early example is constructing even positive integers in two ways: (1) take in a stream of natural numbers and output the double of each element and (2) take in a stream of natural numbers and output every other input element.
Then creating a stream of the positive rational numbers (including the negative ones isn't hard) to make the point that the rational numbers are countable.
Finally create a stream whose input is a stream claimed to include all the real numbers and show that a stream of numbers not included in the input stream can be computed. Each real number can be represented by a stream of digits.