[<<][meta_siso][>>][..]
Sun Jul 19 17:55:57 EDT 2015

Let's ask on the Haskell list

( this is turning into a rubber duck debugging session... )

Does this ring a bell?

Compared to Arrow's
(>>>) :: a b c -> a c d -> a b d

Is there something that captures the idea of "growing arrows"?

(>>>') :: a s1 b c -> a s2 c d -> a (s1,s2) b d

It pops up in multi-stage programming, when composing code that has an
interpretation that behaves as an arrow.

For instance:

(s,i) -> (s,o), not an Arrow instance, corresponds to the code of a
stream processing function ([i] -> [o]), which is an Arrow instance.

What I want to do is to use the Arrow class to build compositions that
eventuall look like [i] -> [o], and then recover the corresponding
(s,i) -> (s,o).

E.g. lift all the >>> to >>>'



It seems that a key point here is a way to replay the compositions.
Don't focus on the types: focus on how things are connected, then
replay.

Why not represent things as (f,c) where f is a functional model and c
is code.  f is actually derived from c.

So:

- Use arrows for composition
- Pass in different primitive types to evaluate.

Actually, 's' in s -> (a i o) could be a network, represented as a
list of operations on a primitive set.  Start simple: a concatenative
program, and after generalize that to arbitrary arrow ops.  Then to
build the program, interpret it to "unfold" into a structure.

So instead of thinking of the state as a parameter, think of the
semantics as a parameter.




[Reply][About]
[<<][meta_siso][>>][..]