Hello Iavor, Wednesday, March 22, 2006, 8:49:29 PM, you wrote:
whenM :: Monad m => m Bool -> m a -> m () ID> One thing about 'whenM' however is that to implement it I'll need to ID> add an extra ID> 'return ()' to the parameter computation. This is probably not a big deal, but ID> given that most of the time the computation used in 'whenM' is already ID> of type 'm ()', I wonder if leaving it to the programmer to add the ID> 'return ()' is not a better idea. ID> What do you think?
that is a sort of thing that bother me constantly. `when` has the same problem. i as application programmer want to write less unnecessary code
ID> Perhaps 'constantly' is too strong of a statement? I very rarely run ID> into problems like that, because mostly I use the results of ID> computations, but maybe this is just my style. I see some benefit to ID> writing an explicit 'return ()', because it becomes more obvious that ID> we are ignoring the (meaningful, that is not ()) result of a ID> computation. we say here about type of `when` and `whenM`: either whenM :: Monad m => m Bool -> m a -> m () or whenM :: Monad m => m Bool -> m () -> m () in both cases value of second argument cannot be used. third possible variant is: whenM :: Monad m => m Bool -> m a -> m (Maybe a) and whenM_ :: Monad m => m Bool -> m a -> m () the same can be applied to the ifM/ifM_
class hierarchy don't matter for application programs in most cases. may be it's better to have "mtl emulation module" and give it (in ghc 6.6) the same name as mtl module has currently. so new apps will use your library directly and other apps will use it through emulation. i use the same technique for my own Binary-replacing module
ID> I am not sure why you think that class hierarchies don't matter to ID> programmers. In fact Java programmers seem to like them a lot. All I ID> meant is that because the class hierarchy differs, some of the ID> operations not only have different names, but also they have different ID> types. i mean that it's impossible to do application programming without knowing names of operations in used libs, but it's possible without knowing of class hierarchy in used libs and even class names at all. i personally prefer in application programming to omit type declarations completely ID> I am not particularly interested in creating an 'mtl' compatibility ID> module, because I think it will create confusion (the libraries are ID> similar enough as it is). People that want to use 'mtl' can use it ID> directly, using 'monadLib' through an 'mtl' compatibility mode does ID> not buy you anything (perhaps the WriterT in 'monadLib' is faster, but ID> I am not sure how big of a deal that is). I think the main benefit of ID> 'monadLib' is that it has a nicer interface than 'mtl'. if so, then you can skip this
i think that support for Typeable in any library is a "good form" now, like support for monads itself :) ID> I am not a big believer in adding things to a library because they ID> might be useful one day. I think that one should first use stuff in ID> their programs, and once they notice that some bit of code appears a ID> lot, than perhaps it should be added to a library. For example, I ID> wrote very many monads before I started using monad transformers, and ID> all the instances were the same -- very boring. These days I very ID> rarely create instances of the monad class. So I think that I could ID> add support for 'Typeable', but I'd rather do it when I know of some ID> compelling examples.
well, i can say in another way - it's the same as adding instances of read/show/eq/ord for data structures. Typeable is used for generic/dynamic programming, see "scrap your boilerplate" papers
ID> I am aware of that, and once they are released I will probably make ID> use of them, because I think that they have some nice ideas. In the ID> mean time however 'monadLib' provides 'Monad.ForEach' and ID> 'Monad.Combinators'.
i think that it's better not to wait while they will be released, but after your MonadLib will be stabilized, propose to include it in 6.6 and develop version of lib that is compatible with 6.6 (if your library goal is to replace mtl)
ID> I can't really use the stuff until it is released, unless (I guess) I ID> copy-and-pasted it into my library, which does not seem like the right ID> thing to do. While I wouldn't mind the library replacing 'mtl' (this ID> was the original idea from some time ago) I am not sure if that is ID> feasible (backward compatibility and what not). Also I think that ID> libraries should be used a little more before they become "standard", ID> so far I think I am the only real user of 'monadLib'. ID> By the way what do you mean "compatible with 6.6"? I don't have a ID> copy of that because it is not released (and if I understand correctly ID> will not be for some time yet). My library uses only what I consider ID> "standard" extensions to Haskell'98 (some rank-2 poly, and ID> multi-parameter type classes with functional dependencies). Are any ID> of these likely to go away in 6.6? Applicative and other classes, written by Ross Paterson, are already included in current HEAD version, i.e. 6.5 beta. if you are interesting in including MonadLib as part of ghc 6.6, you should write appropriate version of your library before ghc 6.6 will be released. if you don't think about this, may be users will force you in this direction :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com