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 tha
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 splitt
Isaac Dupree schrieb:
apfelmus wrote:
Mutable data structures in the sense of ephemeral (= not persistent =
update in-place) data structure indeed do introduce the need to work
in ST since the old version is - by definition - not available anymore.
Not in the quantum/information-theoretic se
apfelmus wrote:
(3+) :: Int -> Int
([1,2]++):: [Int] -> [Int]
insert "x" 3 :: Map String Int -> Map String Int
Of course, from the purely functional point of view, this is hardly
perceived as mutation since the original value is not changed at all and
still available. In other
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 abil
Brian Hulley schrieb:
apfelmus wrote:
However, most "genuinely imperative" things are often just a building
block for a higher level functional model. The ByteString library is a
good example: the interface is purely functional, the internals are
explicit memory control. It's a bad idea to let t