Re: [PATCH] Gnu Elpa: stream.el: Add some more basic stream operations

[Yuri Khan <yuri.v.khan@gmail.com>]

On Thu, Sep 29, 2016 at 1:27 AM, Michael Heerdegen
<michael_heerdegen@web.de> wrote:

> I only partly understand your objection (what do you mean with "strict
> in all elements"?).
>
> IMO, termination in every case is not a requirement, else, we would not
> have `while'.  Formulating algorithms to use streams is just a way to
> describe loops.  So I don't see why it would be a problem when stream
> primitives potentially don't terminate.

In lazy computations, an algorithm is said to be strict (or eager)
with respect to its argument if it forces the computation of that
argument’s value.

Streams are in essence lazy lists. As such, they bring a new
possibility to the table: while a list is limited by the available
memory, a stream is potentially infinite. Solving algorithmic problems
in terms of lists requires reasoning about termination. Yes, this is
the same as with loops — it’s just that loops force such reasoning
while with streams the issue is easy to overlook.

>> As an example, if you want a subsequence starting at the first odd
>> number or at index 1000, whichever is earlier, (seq-drop (min 1000
>> (seq-position-if 'odd S)) S) will not do the right thing.
>
> Would adding an optional argument that allows to specify an upper limit
> for the indexes the function looks at cover (all of) your concerns?

That was just an example. Real users will have other needs. If given a
primitive that returns an index of something, they will try solving
their problems in terms of that index. It is an interface that is easy
to use incorrectly.

But please do not let my theoretical concerns stop you from
implementing useful things. A working implementation is the surest way
of gaining collective experience about a tool.