Push vs pull, rather than imperative vs functional, as the crux of the inversion issue makes a lot of sense to me.  And I see your point about publish/subscribe removing the dependency inversion, while keeping a push implementation and an imperative style.  I also see how pull can be done easily in an imperative setting.  As for doing push in a functional approach, do you mean under the hood, or somehow a visible push model?  Phooey does push under the hood, but hides it from the user.  I don't know what a functional, visible push model would look like.
<br><br>If I understand your final paragraph below, you're describing what I'm up to with Phooey: specify connections (dependencies) in a simple, declarative way, and have the notifications all set up correctly.<br><br>Thanks for your comments, Steve.&nbsp; They're getting me closer to a clear explanation, which will be helpful in the paper I'm writing.
<br><br>Regards,&nbsp; - Conal<br><br><div><span class="gmail_quote">On 12/13/06, <b class="gmail_sendername">Steve Schafer</b> &lt;<a href="mailto:steve@fenestra.com">steve@fenestra.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 12 Dec 2006 17:54:26 -0800, you wrote:<br><br>&gt;Notice that although, logically, the output depends on the input (being a<br>&gt;rendering of its square), the code places into the input widget a dependency<br>&gt;on the output widget, because the output widget contains the mutable state
<br>&gt;altered by the input widget's event handler (upd). Moreover, the output<br>&gt;widget contains no reference to the input widget.&nbsp;&nbsp;Thus, the implementation<br>&gt;dependencies are opposite of the logical dependencies.&nbsp;&nbsp;This inversion of
<br>&gt;dependencies would seem to be a direct result of the imperative approach,<br>&gt;which states the actions that must be taken on the output state as a<br>&gt;consequence of changes to the input state.<br><br>I don't think it's the result of an imperative vs. functional approach.
<br>It's basically a matter of push vs. pull, and while the functional<br>(especially lazy functional) approach is most naturally a pull<br>technique, you can do both push and pull using either imperative or<br>functional approaches. In fact, before the advent of event-driven
<br>programming (the ultimate push technique), most user interaction in<br>imperative programming was based on pull techniques. (And it's somewhat<br>ironic that event-driven programming is typically implemented via a<br>
polling loop or other such pull mechanism.)<br><br>The bottom line is that you have to respond to sequenced, asynchronous<br>events, which are awkward to model using purely pull techniques. You can<br>alleviate some of the &quot;invertedness&quot; of the dependencies by using a
<br>publish/subscribe model, where the subscriber (the output widget in this<br>example), subscribes to notifications by registering itself with the<br>publisher (the input widget). It still ends up working more or less the
<br>same way under the hood, but at least the only _explicit_ linkage<br>visible in the source code goes from output widget -&gt; input widget<br>rather than the other way around.<br><br>I haven't studied Fran or the other functional user interaction
<br>implementations in any detail, so it's possible that I'm repeating<br>something here that they already do, but I think the most useful thing<br>that could come out of any work in this area would be a notation that<br>
allows the programmer to set up the notification links in some sort of<br>declarative way (i.e., &quot;This is how all of the widgets are supposed to<br>be hooked up together&quot;). There are still some sticky bits, because
<br>there's always the possibility that the order in which the connections<br>are wired up will have an effect on whether the final contraption works<br>as expected, but it should be possible to avoid problems in that regard
<br>with the addition of some dependency notations.<br><br>Steve Schafer<br>Fenestra Technologies Corp.<br><a href="http://www.fenestra.com/">http://www.fenestra.com/</a><br>_______________________________________________
<br>Haskell mailing list<br><a href="mailto:Haskell@haskell.org">Haskell@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/haskell">http://www.haskell.org/mailman/listinfo/haskell</a><br></blockquote></div>
<br>