Adde wrote: >> Do you want to mix differently typed Connections inside a single >> transaction? It looks like you don't, so you may well leave out >> existential types altogether and simply parametrize the Transaction >> monad on the type of the connection it uses. >> >> data Connection c => TransactionState c = TS c >> data Transaction c a = >> Transaction (TransactionState c -> (a, TransactionState c) >> >> instance Monad (Transaction c) where ... >> >> getConnection :: Transaction c c >> ... >> >> Note that Control.Monad.State does the same. > > You are correct in that I don't want to mix different kind of connections > inside a single transaction. I just didn't want to have to parameterize every > single function using the monad. > > doSomething :: Transaction FirebirdConnection () > > doSomethingElse :: Transaction FirebirdConnection () > > Maybe I'm misunderstanding something but as I see it that would kind of stop > me from running doSomething and doSomethingElse using different kinds of > databases.
Your monadic action may well be polymorphic in the state type: doSomething :: Connection c => Transaction c () doSomethingElse :: Connection c => Transaction c () thus working for all databases. In case your function really depends on a particular database vendor, you have the possibility to annotate this in the connection type: doSomethingThatOnlyWorksForFirebird :: Transaction Firebird () The additional 'Connection c' constraint in the first examples may be a bit unwieldy. But I guess that you can drop when redesigning your monad. After all, I'm unsure what you intend 'Transaction' to do. Wouldn't runTransaction :: Transaction c a -> IO a be a function you need? Shouldn't things of the Transaction monad be completely back end independent so that you can drop the parameter c altogether? Why do you intend 'Transaction' to be a state monad, I mean why is the only thing you can do with the state something of type (c -> String -> IO ())? Btw, this has been (c -> String -> Transaction ()) in your original post. Regards, apfelmus _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
