[Haskell-cafe] FP design

Levi Stephen levi.stephen at optusnet.com.au
Wed Nov 7 20:41:26 EST 2007

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?


More information about the Haskell-Cafe mailing list