Stream programming

[Nathan Rice]

>>>  I will use "<=>" to mean "is equivalent to". That's not part of the DSL.
>>>  A flow has one or more streams:
>>>   1 stream:
>>>     [1,2,3]
>>>   2 streams:
>>>     [1,3,5] | [2,4,6]
>>>  Two flows can be concatenated:
>>>   [1,2,3] + [4,5,6]<=>  [1,2,3,4,5,6]
>>>   [0] + ([1,2] | [3,4]) + [10]<=>  [0,1,2,10] | [0,3,4,10]
>>>   ([1,2] | [10,20]) + ([3,4] | [30,40])<=>  [1,2,3,4] | [10,20,30,40]
>>
>>
>> Algebraically, your concatenation rules don't really make sense - your
>> flows are both distributive and non distributive.  You also make the
>> implicit assumption of an order over streams in a flow, but disregard
>> the implications of that assumption in some cases.  I understand what
>> you're trying to communicate, so I think you need to be a little more
>> strict and explicit in your definitions.
>>
> When concatenating, either there are the same number of streams, or one
> of them is a single stream which is duplicated.
>
> Therefore, in this example:
>
>    [0] + ([1, 2] | [3, 4])
>
> you're concatenating a single stream with a pair, so the single stream
> is duplicated:
>
>    ([0] | [0]) + ([1, 2] | [3, 4])
>
> and then they can be concatenated:
>
>    ([0, 1, 2] | [0, 3, 4])
>
> However, this:
>
>    ([0, 1] | [2, 3]) + ([4, 5] | [6, 7] | [8, 9])
>
> won't work.

I understand how he wants the system to work in this case; my point
was that it isn't consistent.

He stated flows can be concatenated, so [0] is just a flow of a single
stream.  Because he clearly intends that streams in a flow are
ordered, that indicates that he wants some sort of algebraic module.
He could get close if he can extend a stream to meet the requirements
of a ring, then a flow would be a module over the ring of streams.
The problem he is going to run into is that operations on streams as
he defines them are not commutative.  Identity elements for the two
binary operations are also not immediately obvious to me.

He could just be smart and use the pi calculus, it is rigorously
developed and can model his desired behavior, if he reformulates it
slightly.

Another option is just to give up on being rigorous.  Given the
abstract treatment he attempted I would be disappointed, but if his
only goal is to get practice writing code and he isn't interested in
exploring the conceptual space of the problem domain it would be the
right decision.