[Haskell-cafe] Re: Language support for imperative code. Was: Re: monad subexpressions

[Brian Hulley]

Brian Hulley wrote:
> apfelmus wrote:
>> Brian Hulley schrieb:
>>>    main = do
>>>            buffer <- createBuffer
>>>            edit1 <- createEdit buffer
>>>            edit2 <- createEdit buffer
>>>            splitter <- createSplitter (wrapWidget edit1) (wrapWidget 
>>> edit2)
>>>            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.
>>   http://www.st.cs.ru.nl/papers/2005/eves2005-FFormsIFL04.pdf
>
> 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,

Brian.