Are we being mocked by a limey? 
(I read the other day they haven’t even decided yet on the standard side for oncoming pedestrians to pass each other. 
)
You’re the editor-in-chief of libraries, and General Overall Director of all this anyway, so if we persistently disagree, you decide - that’s fine with me. Meanwhile I enjoy discussing from various viewpoints, that’s what brings about progress.
I’ll take a look at your post later today, after I get home from work.
OHHH, @bh =
No, he's an american Berkeley professor emeritus.
Explain this!
Was I mocking? No, that was a reference to @cymplecy.
I wish I were English. I used to hang around on Oxford St. just listening to people talk as they passed by, because I love the accent. (The, you know, BBC accent, not the ones I can barely understand.)
Please delete all the off-topic posts - sorry for the noise
Yeah, I agree the 2nd block is not going to win any beauty pageants. I do have some reservations regarding your proposed solution, though:
tail of stream, which was so nice and simple before;We already have a block limiting the number of items from a stream (copy stream until), that could be used as an alternative. Besides we don’t really need find first-stream at all, as the same effect can be produced by item (1) of stream (keep (function) from stream).
See this ad hoc project.
find first-item: it wasn’t necessary for this purpose.
So … shall we just drop find first-stream (and index of (thing) in stream, which probably isn’t going to be very useful anyway) ?
O, we were just having some fun, weren’t we?
Besides, the bet is on 
Yes, agreed.
I got it to work after all. Just not happy with the “result” which should not be an error.
Plus it requires initialisation, which I’m not a fan of.
And my suggestion to drop two blocks still stands.
Why not? What should it be? If you didn't find a result, you don't want to continue the computation anyway, do you? Or, I guess you might, but then you'd use a SAFELY TRY, just as you would for any other anticipated error. You don't want to continue the computation with some default value that wasn't actually found in the stream, is what I mean.
In a perfect world, FIND FIRST would really be FIND FIRST INDEX and would report -1 or something if nothing satisfies the condition. I mean, for lists, too.
I know what you mean about initialization, but that's going to be more and more common as libraries grow into extensions, I think.
You broke the grouping of the category by saving it in v9 instead of v10. :~(
On the subject of error handling, why can't I get the block to behave this way:
I hoped that putting "else" in the "separator" field would do this, but no such luck. This would be perfect, because if you want to return some value when the computation asks for too many tails, you can click the arrow. But if you don't click the arrow, you get an error message on overtailing.
Your proposed use of COPY STREAM instead of my idea has the disadvantage that it makes the user think about the below-the-line view of the stream abstraction. I think the user should write the stream expression as if it's guaranteed that the desired item will be found in the stream, and only then, take the entire perfect stream expression and wrap a tail limit around it. (And by the way, when I first read it, I thought COPY STREAM would actually copy it right up front, like LIST-ITEMS, because the word "copy" in its name painted so strong a picture in my mind. I don't have an alternative name to propose right now but I want to think about that.)
The other thing about STREAM-LIMITED vs. COPY-STREAM is that the latter makes you know exactly what stream isn't cooperating, whereas the former doesn't care where the problem arises.
Dropping blocks: I guess to a first approximation I want users to be able to take a list program and wave a magic wand over it to drop "stream" into the names of all the blocks and have it work. (In a really perfect world, instead of a new category, the user would throw a switch and the plain old list blocks would start doing lazy evaluation! Like the bignum library. But I'd never in a million years get that past Jens.) But anyway, that's why I want FIND FIRST. I agree with you that if you're writing a stream program from scratch you don't need FIND FIRST because the library isn't going to compute more than the first item of a KEEP unless you take the tail of the result. So HEAD OF (KEEP...) is already efficient. But if you already wrote a list-based function and you're streamifying it, this just lets you not think about why there isn't a FIND FIRST.
As for INDEX OF, you're not going to use it to, e.g., swap two items of a stream, but you might
I dunno.
I don't have strong feelings about this. I'm pretty happy if I can generate the stream of all the primes! You're the one who needs this for a practical project. :~)
I see your point, let me think about it.
I sometimes use this one:
It's just been a sandbox project, not intended as a new library version
Yes, it might.
Allow? Permit? Facilitate? Convey? Pass on? Laissez passer? Cut off ... after?
I agree; and many of the blocks we have developed are heavily inspired on list equivalents. However some list operations don't have meaningful equivalents in the stream domain (e.g. reverse).
I'm not even sure the mechanism works (correctly) if it's applied at several points within a script, let alone multiple scripts. Did you test this?
Never say never!
This is my proposal for finishing the library update, please let me know what you think of it
max. search parameters from find-first-stream and index-of-stream, as we can do without them anyway, with copy-stream-until (by any name) as a workaround;I implemented my above proposal here (within the v10 IDE).
max. search parameters from find-first-stream and index-of-stream;for each block (another meaningful equivalent of a list block; it doesn't work with upvars); added stream-contains, too;stream limited to block and two streams being evaluated in parallel; I found however one of the streams will continue to be evaluated indefinitely!Yeah, about that...
Well, what about it?
The bignum library COULD use some work.
If you are serious about this: create a separate topic specifying what you would think should be changed.
... Look, I'm serious, I just don't have enough TIME right now to make a separate topic. I'll probably do it later.
Oh I see. I was thinking about nested STREAM LIMITEDs, rather than parallel ones. Good catch. I guess this is a legit use for dynamic scope that even Jens will agree is legit. Fortunately we can use THIS CALLER to achieve that now. I don't have time right now but I'll fix this up this afternoon. I think that'll even get rid of the initialization you don't like. :~)
I wonder if we should have a third truth value, next to true and false: undetermined? To be used if a query is aborted because no answer was found within certain practical limits (such as a reasonable amount of time).