[Haskell-cafe] Re: Re: Language support for imperative code. Was:
Re: monad subexpressions
benjamin.franksen at bessy.de
Mon Aug 13 18:11:58 EDT 2007
Brian Hulley wrote:
> 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.
I'd be careful. Introducing a network connection into the equation makes the
object (its methods) susceptible to a whole new bunch of failure modes;
think indefinite delays, connection loss, network buffer overflow, etc etc.
It may be a mistake to abstract all that away; in fact I am convinced that
the old Unix habit of sweeping all these failure modes and potentially long
delays under a big carpet named 'file abstraction' was a bad idea to begin
with. The ages old and still not solved problems with web browsers hanging
indefinitely (w/o allowing any GUI interaction) while name resolution waits
for completion is only the most prominent example.
More information about the Haskell-Cafe