On 20/06/11 16:37, David Barbour wrote:

On Mon, Jun 20, 2011 at 7:45 AM, Richard Senington mailto:sc06r2s@leeds.ac.uk> wrote:

I have recently become interested in Dataflow programming and how it related to functional languages. I am wondering if the community has any advice on reading matter or other directions to look at.

So far I have been looking through the FRP libraries, using Haskell functions with lazy lists for co-routines and the Essence of Dataflow Programming by Uustalu and Vene where they propose using co-monads.

It looks as though Iteratees are also relevant but I have not got round to looking at them in detail yet.

Have I missed anything?

Arrows are a useful model for dataflow programming. But several FRP models are arrowized, so you might already have observed this. Which FRP models have you looked at? (there are several)

I'm developing a model for reactive dataflows in open distributed systems, called reactive demand programming (RDP). It's basically distributed FRP with carefully constrained side-effects and signals that model disruption. The effects model enforces spatial idempotence and commutativity, which allows developers to perform refactoring and abstraction similar to that in a pure functional model. That signals model disruption allows 'open' composition and extension (e.g. runtime plugins). RDP is more composable than FRP because client-server relationships can be captured as regular RDP behaviors.

RDP isn't ready for release, yet, but you can read a bit more at my blog:

[1] http://awelonblue.wordpress.com/2011/05/21/comparing-frp-to-rdp/

Regards,

David Barbour

I have been looking through the papers by Conal Elliott and Paul Hudak, Hudak's book "The Haskell School of Expression" (chapters 13,15,17) and the latest version of the Reactive library on Hackage. In the past I have looked at Arrows, but I think I should have another look now, thanks for the suggestion. RS

On Tue, Jun 21, 2011 at 3:18 AM, Richard Senington wrote:

I have been looking through the papers by Conal Elliott and Paul Hudak,

Hudak's book "The Haskell School of Expression" (chapters 13,15,17) and

the latest version of the Reactive library on Hackage.

In the past I have looked at Arrows, but I think I should have another look now, thanks for the suggestion. Hudak's 'Yampa' is a reactive arrows model, which I believe started with some of his older work on Frob (functional reactive robotics). There are a few documents out there of the form "Arrows, Robots, and Functional Reactive Programming" [1][2]. Ross Patterson's early work on arrows also provides example of using of Arrows to model synchronous circuits as a form of dataflow programming [3]. Conal's 'Reactive' is an interesting study, but I don't like the model - it implicitly uses unsafePerformIO and futures under the hood to capture real-time behaviors, but I feel that 'real-world' integration should be captured more explicitly by our models. [1] http://people.cs.uu.nl/johanj/afp/afp4/hudak.ppt [2] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.5.2886&rep=rep1&type=pdf [3] http://www.soi.city.ac.uk/~ross/papers/notation.html (section 6)

On Tue, Jun 21, 2011 at 12:14 PM, Edward Kmett wrote:

The essence of data flow programming describes how you can use comonads to model the semantics of dataflow languages.

One of the best stops from there is probably, Dave Menendez's response on the Haskell mailing list back in 2005 summarized how one can move from building a semantics for dataflow programming using comonads to actually implementing dataflow programming directly using comonads. This is useful if you don't want to write a dataflow language compiler or interpreter, but instead just want to write some dataflow code in the middle of your program as an embedded domain-specific language.

http://www.haskell.org/pipermail/haskell/2005-September/016502.html

Comonads are useful for describing dataflow operations and for making simple implementations, but they can have serious performance problems if your goal is to obtain intermediate results. Still, it's useful to see what sorts of things are possible with comonads and how they translate into other, more efficient implementations. I should also note a few errors in my 2005 e-mail: 1. CoKleisli arrows are *not* an instance of ArrowApply, as they do not satisfy the composition law. That is, app . arr ((h .) *** id) /= h . app 2. Defining ArrowLoop does not require a zip operation. You can define the instance like so: instance Comonad c => ArrowLoop (Cokleisli c) where loop f = C $ fst . f' where f' = unC f . coextend (extract &&& snd . f') This incidentally, was inspired by a more recent definition of cfix, cfix :: Comonad f => (f (a,b) -> b) -> f a -> b cfix f = f . coextend (\c -> (extract c, cfix f c)) (Exercise: define the cfix in my 2005 email in terms of this one, and vice versa.) 3. You don't need cfix to write recursive comonadic code. For example, pos (which is initially one and then increments), can be defined using cfix: pos :: History a -> Int pos = cfix (\ctx -> 1 + 0 `fby` fmap snd ctx) but it can also be defined using Haskell's recursion: pos ctx = 1 + 0 `fby` pos ctx 4. Auto is not less powerful than Hist. In fact, any arrow in Hist can be converted to Auto, and vice-versa. Similarly, Auto forms a monad in the same way Hist does. -- Dave Menendez http://www.eyrie.org/~zednenem/