Talk:Applicative data-driven programming
Add topicHi 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. 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. 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 liftA2 (+) s s, the effect of the signal s is doubled, meaning that the widgets belonging to s are created twice—with different IDs for the different instances. So you have no advantage here. On the other hand, if you use liftA (\a -> a + a) s, there is no double notification since you use a unary function in fact. Am I missing something here? -- Wolfgang Jeltsch 17:20, 2 June 2007 (UTC)
- I think the answer depends on which applicative functor (AF): data-driven computations (
DataDriven nfr xtr, e.g. Source) or UIs. Redundant notification (eliminated with unique IDs) can arise from direct use ofSource. 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! --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! --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. --Conal 01:36, 3 June 2007 (UTC)
- Hello Falcon, have you read Applicative programming with effects by Conor McBride and Ross Paterson? In my opinion, it’s a very comprehensible introduction to applicative functors. -- 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 :) ). --Falcon 05:52, 4 June 2007 (UTC)
Typo: In 1.2, third paragraph "... an widget ... " -> " ... a widget ..." -- Bas van Dijk 21:32, Jun 3 2007 (UTC)