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

[Isaac Dupree]

Brian Hulley wrote:
> 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.

Probably it would be parametric in the input mechanism, somehow.  (A 
Haskell approach might use type classes, slightly obscuring the 
parametricity..)

> 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.

Jef Raskin (late interface designer, author of _The Humane Interface_) 
would probably say that anything with such importance to user decisions, 
should be rendered within a tenth of a second.  Computers fifteen years 
ago could sometimes do it!  Fancy details can be filled in later if it 
takes that long.

Of course that completely dodges the mathematical question... in which 
human response time should really be taken into account too! Humans 
really are not like machines and are not all alike either!  Oh no, do we 
need psychological formalisms?

Firefox suffers the above problems badly, alas - the "Stop" button is 
half useless because it doesn't even noticed you pressed it for such a 
long time, etc...

Reading up on user interface design principles as well as thinking 
functionally, is probably a useful approach - although not everything 
that you read will agree or be right.  The whole concept of GUIs - they 
are very complicated - it is quite arguable that they are just a wrong 
interface - however, some of the world's people are fortunate enough to 
be accustomed to them already, which complicates matters considerably.


Isaac