On 12/12/06, Brian Hulley <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
