Re: [Haskell-cafe] Re: OO Design in Haskell Example (Draft)

"Steve Downey"
I'm not sure, though, what would happen if I tried to add state to the types. With the previous example, using existentials to create a reference type that holds elements of a type class that matches the interface, I think that it would be natural to hold state by having that element stored in a mutable state variable, and replacing the held values.
State is often best avoided, but if it's really what you want to do, you can still capture a mutable variable in the closures captured inside the record of functions. Tim import Data.IORef data Component = Component { draw :: IO (), move :: (Int,Int) -> IO () } newCircle :: IO Component newCircle = do pref <- newIORef (0,0) return Component{draw=draw' pref, move=move' pref} where draw' pref = do p <- readIORef pref putStrLn ("circle at " ++ show p) move' pref p = writeIORef pref p

Hi folks forgive my ignorance but I thought functional programming was a mathematically sound framework unlike Object Oriented programming. Isn't using Haskell for OOP kind of defeating the whole object? And the pun wasn't deliberate./ Honest! Regards Paul

Hi
forgive my ignorance but I thought functional programming was a mathematically sound framework unlike Object Oriented programming.
Referentially transparent is a better term than mathematically sound here. This is the property that x = y means that instances of x can be replaced with y.
Isn't using Haskell for OOP kind of defeating the whole object?
It is defeating the point of expressing programs in a beautiful way, but if you are building it on top of Haskell, without going to things like unsafePerformIO, then you still end up with a referentially transparent framework. Thanks Neil
participants (3)
-
Neil Mitchell
-
P. R. Stanley
-
Tim Docker