On Thu, Jan 7, 2010 at 5:15 PM, Felipe Lessa
On Thu, Jan 07, 2010 at 04:00:31PM +0100, Bas van Dijk wrote:
As I explained in my announcement of 'safer-file-handles', I discovered a serious lack of expressive power in my 'regions' package. I have now solved that problem in the way I envisaged by removing the 'resource' parameter from 'RegionT' and using existential quantification to bring the 'resource' type back at the place I need it but hidden from the outside.
But if I understand correctly, now you can't know from the type signature what kind of resource a given code accesses. Isn't this a drawback? Wouldn't it be better to write something like
TopRegion (File `And` Network)
to tell something needs both?
Oh yes, very good point! Lets think, I could parameterize RegionT by some sort of heterogeneous list (HList) that encodes all the resources that the region opens. However won't this introduce my previous problem again? Another solution might be to encode the resources that a region opens as constraints. I think 'control-monad-exception' uses a similar technique to encode all the exceptions that a monadic computation may throw. My previous program could then possibly be written as something like: openBoth ∷ ( resources `Contains` Device , resources `Contains` File ) ⇒ Device → FilePath → RegionT resources pr () openBoth usbDevice filePath = do h1 ← open usbDevice h2 ← openFile filePath ReadMode return () Thanks for bringing up this point! Bas [1] http://hackage.haskell.org/package/control-monad-exception