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 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
There's a loud voice in my head screaming FRP, 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 ):
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:
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 sounds interesting.