Tim Docker wrote:
levi.stephen wrote:
I have similar questions about Haskell abstracting away implementations behind interfaces as well. I have become used to an approach where I will not worry about databases/persistence when beginning. I will create an interface to a database layer (e.g., save(object), retrieve(id), findByName(name)) etc., and an implementation that uses in memory collections to begin with. Later I will replace this with database calls.
How does this type of approach work in Haskell? or what is the Haskell way to achieve this?
If OO is a good approach for a problem, it's straightforward to model it in haskell. If you plan to access an external DB in any case, then the interface will involve the IO Monad. Something along the lines of:
data Object data ID
data ObjectStore = ObjectStore { save :: Object -> IO ID, retrieve :: IO -> IO (Maybe Object), retrieveByName :: String -> IO (Maybe Object) }
createMemoryStore :: IO ObjectStore connnectExternalStore :: ConnectionParams -> IO ObjectStore
Tim
Thanks for the example. I keep forgetting that I can have use functions like this. I keep having data types made up of just values and/or type classes. I should probably use types like the above more often. My concern (which may be inexperience ;) ) is with the monads here though. What if I hadn't seen that the IO monad (or any other Monad) was going to be necessary in the type signatures? Levi