[Haskell-cafe] FP design

[Levi Stephen]

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