[Haskell-cafe] Re: Language support for imperative code. Was:
Re: monad subexpressions
brianh at metamilk.com
Mon Aug 13 17:28:11 EDT 2007
Brian Hulley wrote:
> apfelmus wrote:
>> Brian Hulley schrieb:
>>> main = do
>>> buffer <- createBuffer
>>> edit1 <- createEdit buffer
>>> edit2 <- createEdit buffer
>>> splitter <- createSplitter (wrapWidget edit1) (wrapWidget
>>> runMessageLoopWith splitter
>>> ... Thus the ability to abstract mutable state gives to my mind by
>>> far the best solution.
>> I'm not sure whether mutable state is the real goodie here. I think
>> it's the ability to indpendently access parts of a compound state.
> This is indeed a real key to the problem.
Of course this is only one aspect of the problem...
Thinking about this a bit more, and just so this thought is recorded for
posterity (!) and for the benefit of anyone now or in a few hundred
years time, trying to solve "Fermat's last GUI", the object oriented
solution allows the buffer object to do anything it wants, so that it
could negotiate a network connection and implement the interface based
on a shared network buffer for example, without needing any changes to
the client code above, so a functional gui would need to have the same
flexibility to compete with the OO solution.
Another thing that would be interesting would be to have a formal
treatment of what is supposed to happen in a gui. For example, when you
move the mouse over a control which has become dirty (ie needs to be
re-rendered because its state is now inconsistent), what should the
control do? Should it respond as if the new state were already visible
to the user, or should it interpret the mouse position according to the
last state that was rendered, or should it just ignore all mouse events
until the next time it gets rendered? This is not a trivial question
because you could imagine an animated control where the user might
naturally be following the movement, whereas when the user clicks on a
cell in a spreadsheet when the cells to the left have now expanded due
to a change in data thus moving the cell along (but where this updated
model has not yet been re-rendered) the user might be irritated at the
wrong cell being selected... It's tricky little issues like this that I
haven't found any documentation for anywhere, and which would make a
proper mathematical treatment of interaction with a gui very useful,
regardless of whether it is implemented in OOP or functional style.
Anyway just a thought,
More information about the Haskell-Cafe