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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
