Subject: Re: monad library - msg#00024

Previous Message by Date: click to view message preview

monad library

hello, i was wondering what people think about the following two issues with the monad library: 1. there are the map* functions for different transformers (mapReader, mapWriter, etc.). does anyone use them for anything? while there is something common between them, i am not quite sure exactly what it is. if anyone is using them i would be interested if the same can be achieved by just using the "standard" functionality for the appropriate transformer. i am inclined to remove them from the library, if there are no objections. 2. currently the monad library is under Unstable.Control.Monad, and i would like to move it to some other place, so that we can use it, without the need to later rename everything. the core of it should be more or less stable. since moving libraries at the moment is quite work intensive, it would be nice if we agreed on where to put it, so that we don't have to move it again. i propose that we put all the monads under Monad, thus one would import Monad.State, Monad.ReaderT, or Monad.Transformers. in this way the old monad library can stay under Control.Monad and programs that are using it need not change. at some point in the future we can decide to remove the old library or it can just stay there. and i like the shorter names (not to mention that it is not clear what some of the monads have to do with control). any comments? iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

Next Message by Date: click to view message preview

System.Directory (was RE: Proposal for a new I/O library design)

Hi guys, I'm not replying to anything in the message, but... > Is the idea > to abstract away from the syntax of pathnames on the platform (eg. > directory separator characters)? If so, I'm not sure it's worthwhile. > There are lots of differences between pathname conventions: case > sensitivity, arbitrary limits on the lengh of filenames, filename > extensions, and so on. Would there be any way to get some of these differences into the System.Directory structure? At least the following would be nice: > pathSeparator :: Char > '\\' on Windows, '/' on unices, ':' (I believe) on macs, etc... > directorySeparator :: Char > ';' on Windows, ':' on unices, i have no idea on macs > isCaseSensitive :: Bool > False on Windows, True on (all?) unices, i have no idea on macs given just these, i think we'd all be a lot happier. I also don't particularly care whether these are IO operations or just values (so long as they are constant, they might as well be values with unsafePerformIO wrapped around them if necessary). My current approach to figuring this out is to create a directory, change to that directory, get the current path name and try to parse it. This is bad for so many reasons I won't enumerate them here. ...unless this stuff is hiding somewhere else, please let me know (but System.Directory would probably be a good place for it to end up)... - Hal

Previous Message by Thread: click to view message preview

monad library

hello, i was wondering what people think about the following two issues with the monad library: 1. there are the map* functions for different transformers (mapReader, mapWriter, etc.). does anyone use them for anything? while there is something common between them, i am not quite sure exactly what it is. if anyone is using them i would be interested if the same can be achieved by just using the "standard" functionality for the appropriate transformer. i am inclined to remove them from the library, if there are no objections. 2. currently the monad library is under Unstable.Control.Monad, and i would like to move it to some other place, so that we can use it, without the need to later rename everything. the core of it should be more or less stable. since moving libraries at the moment is quite work intensive, it would be nice if we agreed on where to put it, so that we don't have to move it again. i propose that we put all the monads under Monad, thus one would import Monad.State, Monad.ReaderT, or Monad.Transformers. in this way the old monad library can stay under Control.Monad and programs that are using it need not change. at some point in the future we can decide to remove the old library or it can just stay there. and i like the shorter names (not to mention that it is not clear what some of the monads have to do with control). any comments? iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

Next Message by Thread: click to view message preview

Re: monad library

hello, Andrew J Bromage wrote: 1. there are the map* functions for different transformers (mapReader, mapWriter, etc.). does anyone use them for anything? while there is something common between them, i am not quite sure exactly what it is. I've used them once, and that was to swap the underlying monad of a transformer. It's occasionally handy, for example, when you want your state to be backtrackable for a small part of your code, to stick a backtracking monad _under_ the top monad transformer. I don't think that you can duplicate this behaviour using the other operations on the monad. A simple solution would be to introduce this typeclass: class (MonadTrans t) => MonadMapTrans t where mapTrans :: (m a -> n b) -> (t m a -> t n b) i think this type doesn't quite work as often the underlying computation returns a more complicated type (e.g. the state monad also returns a new state). in my other library i had a similar operation, corresponding to the fact that most monad transformers are functors on the category of monads. it works for all transformers except for continuations: class MondaTrans t => MapTrans t where mapTrans :: (Monad m, Monad n) => (forall a. m a -> n a) -> t m b -> t n b intuitively the "forall" constraint says that we are changing just the monad, and not touching the value. to get continuations to work, one needs a map (n a -> m a) as well, i think. any comments about that class? bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================