[Haskell] ANNOUNCE: Phooey -- a Functional UI library for Haskell

[Conal Elliott]

On 12/12/06, Brian Hulley <brianh at metamilk.com> wrote:

> This looks really interesting, but I'm struggling to understand what you
> mean by "reversal".  Can you elaborate on what you mean by "the imperative
> approach  imposes an implementation dependence of inputs on outputs." In the
> model-view-controller pattern for example, I see no such reversal.
>

I'll try to explain with an example.  If it's not clear, or you think the
reasoning doesn't apply to MVC, please let me know.

The code makes a top-level frame and a panel for holding widgets, creates
slider input and text output.  It then installs event handlers for the input
widget, to change the state of output widget (to show the square of the
input value).  After initializing the output, the code set the panel's and
the frame's layouts and shows the frame.

import Graphics.UI.WX

z1 :: IO ()
z1 = start $
  do  -- Create frame, panel, slider input, and text output
      f    <- frame []
      pan  <- panel f  []
      s    <- hslider pan True 0 10 [ selection := 3 ]
      t    <- textEntry pan []
      -- output-updater to be called initially and when input changes
      let upd = do  n <- get s selection
                    set t [ text := show (n*n) ]
      upd
      set s [ on command := upd ]
      -- Lay out panel and frame
      set pan  [  layout :=
                   fill $ column 0 [ hwidget s, hwidget t ] ]
      set f    [ layout := hwidget pan ]
 where
   hwidget :: Widget w => w -> Layout
   hwidget = hfill . widget

Notice that although, logically, the output depends on the input (being a
rendering of its square), the code places into the input widget a dependency
on the output widget, because the output widget contains the mutable state
altered by the input widget's event handler (upd). Moreover, the output
widget contains no reference to the input widget.  Thus, the implementation
dependencies are opposite of the logical dependencies.  This inversion of
dependencies would seem to be a direct result of the imperative approach,
which states the actions that must be taken on the output state as a
consequence of changes to the input state.

I'll reply separately to your question about efficient evaluation/updating.

Cheers,  - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell/attachments/20061212/3cf563d6/attachment-0001.htm