Difference between revisions of "Talk:Applicative data-driven programming"
Jump to navigation
Jump to search
(addition of question regarding advantages of unique IDs) |
m (Replies to BrettGiles and Wolfgang Jeltsch) |
||
| Line 1: | Line 1: | ||
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) |
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 |
||
| + | |||
| + | ---- |
||
| + | |||
| ⚫ | 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—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) |
||
| + | |||
| + | ---- |
||
Revision as of 18:41, 2 June 2007
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. 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)