View source for Talk:Applicative data-driven programming

Hi Conal - Great to see some programming research here! So far I've just done a cursory review.  The first thing that jumps out at me is that I like the style of the paper, the level of coding and the accesibility of the examples. One part that feels like it is missing is a section (or subsection) discussing ''why'' you chose applicative functors rather than monads or arrows. That is, what is missing or too heavy in those Haskell standards? I'm going to give it a more detailed read and may have more comments later. [[User:BrettGiles|BrettGiles]] 14:54, 2 June 2007 (UTC)

: I'm glad to know the examples work for you.  :)  I like your suggestion about comparing with monadic and arrow approaches (which I also implemented for [[Phooey]]).  I'll add that comparison.  My short answer is that a ''monadic'' formulation forces me to expose sources and more explicit lifting, while an ''arrow'' formulation (my previous favorite) requires an input and an output type, when it's very rare to use both.  Personally, my favorite approach is none of these, but rather the [[TV]] style, because of its composability.  [[User:Conal|Conal]] 18:41, 2 June 2007 (UTC)

----

Hello Conal, could you explain what advantages the use of unique IDs brings?  You give adding a value to itself as an example.  However, if you use <hask>liftA2 (+) s s</hask>, the effect of the signal <hask>s</hask> is doubled, meaning that the widgets belonging to <hask>s</hask> are created twice&mdash;with different IDs for the different instances.  So you have no advantage here.  On the other hand, if you use <hask>liftA (\a -> a + a) s</hask>, there is no double notification since you use a unary function in fact.  Am I missing something here? -- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 17:20, 2 June 2007 (UTC)

: I think the answer depends on which applicative functor (AF): data-driven computations (<hask>DataDriven nfr xtr</hask>, e.g. Source) or UIs.  Redundant notification (eliminated with unique IDs) can arise from direct use of <hask>Source</hask>.  With AF-based or arrows-based UIs, on the other hand, I think your point is right on, since the abstraction prevents direct access to value sources.  Any ''monadic'' UI formulation I've imagined would expose sources, in which case the tagging trick would be helpful.  Thanks again for your penetrating insights!  --[[User:Conal|Conal]] 18:41, 2 June 2007 (UTC)

----

Conal, ever since I read "Another Essence of Dataflow," I've been trying to understand AFs.  Your paper doesn't explain them but makes me more interested in using them for my problem.  My interest is in using AFs for dealing with streaming data, as in stock market quotes.  I would love to be able to say something like: "buy (.1 * lastquantity) msft at bidprice" (in a more Haskellish syntax obviously).  In the previous expression, the system is asked to buy Microsoft's stock, the number of shares to buy is 10% some value in a stream and the price to buy it is equal to another value in another stream.  The system may have two different streams [(time,symbol,lastprice,lastquantity)] and [(time,symbol,bidprice,askprice,bidquantity,askquantity)].  So, can the ideas in your paper be used to solve such 'event processing' problems without littering my code with callbacks or polling current values every few milliseconds?  Thanks! --[[User:Falcon|Falcon]] 21:26, 2 June 2007 (UTC)

: I'd like to explore your application.  If you contact me with more info, we'll see what we can come up with.  I'm delighted with the AF abstraction.  I used them for years without realizing it: Fran/FRP behaviors, Pan images. --[[User:Conal|Conal]] 01:36, 3 June 2007 (UTC)

: Hello Falcon, have you read [http://www.soi.city.ac.uk/~ross/papers/Applicative.pdf Applicative programming with effects] by Conor McBride and Ross Paterson?  In my opinion, it’s a very comprehensible introduction to applicative functors. -- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 20:16, 3 June 2007 (UTC)

::Wolfgang, I have indeed.  Although I must say that it still takes me a while to understand most Haskell papers (and I do read many :) ). --[[User:Falcon|Falcon]] 05:52, 4 June 2007 (UTC)

----

Typo: In 1.2, third paragraph "... an widget ... " -> " ... a widget ..." -- [[User:Bas van Dijk|Bas van Dijk]] 21:32, Jun 3 2007 (UTC)