Mon Dec 24 21:11:31 EST 2012

Model-View-Controller vs. functional GUI

I'm trying to find out why writing GUIs is such a pain, and whether it
is possible to simplify the approach using some functional programming

MVC[2] might make sense in the OO world, but why all this state?  The
problem is really simple: a GUI is an animation that responds to user
input: frame0 -> input -> frame1 -> ...  each frame represents a
different interpreter.

There's a loud voice in my head screaming FRP[1], but I don't see
immediately how everything links up...

There should be a way to relate the idea of cursor into a model tree
(zipper in a model) to cursor into a gui tree.  Can both be the same?
Is there a way to relate model and gui in a more direct way such that
the interface emerges somehow "automatically" ?

I believe that MVC as used in OO world often has not so clear
separation between concerns, but the basic idea is very simple (see
figure in [2]):

           View is generated from Model
           Controller updates Model

Here, the model is usually fiarly obvious.  Generation of View from
Model should be a no-brainer (projection to gui parameters followed by
injection into the drawing system).  Updates from the Controller to
the model should also be simple.

However, the tricky bit is how View and Controller are tied to each
other.  I.e. a mouse click on a canvas probably needs to be dispatched
depending on how exactly it is rendered by the model.

In my own use, I've always found the V/C distincion to be quite
arbitrary.  Maybe I just don't understand, but there seems to be
something missing: something that resembles the "physical".  Maybe
there should be an intermediate point?

       Abstract Model - Physical Model

Where interactions to the physical model are simple physical events,
like one would expect from a game engine, and the constraints of the
physical model are directly mapped to the constraints of the abstract

What about this: define 2 maps a -> p, p -> a, relating the abstract
and physical models in such a way that changes to the physical model
that are not consistent do not map back to the same representation.

What I describe above is almost exactly this[4]:

  One of mind-opening ideas behind Functional Reactive Programming is
  to have an event handling function producing BOTH reaction to events
  AND the next event handling function. Thus an evolving system is
  represented as a sequence of event handling functions.

Reactive Banana[5] sounds interesting.

[1] http://en.wikipedia.org/wiki/Functional_reactive_programming
[2] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
[3] http://broadcast.oreilly.com/2008/10/mvc-as-anti-pattern.html
[4] http://stackoverflow.com/questions/2672791/is-functional-gui-programming-possible
[5] http://www.haskell.org/haskellwiki/Reactive-banana