Stream programming

[Nathan Rice]

>>  I understand what
>> you're trying to communicate, so I think you need to be a little more
>> strict and explicit in your definitions.
>
>
> No, I don't think you understand what I meant.

I don't agree. Sorry.

> Yes. I thought that streams as an alternative to functional programming were
> widely known.

Streams aren't really a paradigm of computation.  They're a semantic
element of a computational system which cuts across paradigms.  If you
want to retract that and say you were talking about dataflow
programming (which is much larger than streams, and actually has a
cohesive definition), I won't hold it against you.  Ultimately though,
functional programming and dataflow programming are closely linked,
the main difference being the use of queues based rather than stacks.

> Isn't that obvious? BTW, those are not rigorous definitions. I thought I was talking to people who regularly works with streams.

That is the GPU mailing list, down the hall on the left.

> Instead of talking of what I wasn't trying to do and, indeed, I didn't do,
> you should try to understand what I wanted to do and, in fact, I did.
> I'm afraid your cup is too full to understand simple things as the one I
> wrote in my OP.

Clearly, because I didn't explicitly include the possibility that you
are just writing throwaway code with no attempt at development of
ideas for the purpose of practicing writing code in the paragraph
after the one you quoted.

If your goal is to learn to code, instead of posting a message stating
that you have a superior way to compose code, you might want to try to
solve a problem and ask others their opinion of the structure and
techniques in your code.