Hello,
Thanks for the feedback! Here are my thoughts on the questions you raise...
On 3/22/06, Bulat Ziganshin
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
Perhaps 'constantly' is too strong of a statement? I very rarely run into problems like that, because mostly I use the results of computations, but maybe this is just my style. I see some benefit to writing an explicit 'return ()', because it becomes more obvious that we are ignoring the (meaningful, that is not ()) result of a computation.
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
i think that support for Typeable in any library is a "good form" now, like support for monads itself :) I am not a big believer in adding things to a library because they might be useful one day. I think that one should first use stuff in
I am not sure why you think that class hierarchies don't matter to programmers. In fact Java programmers seem to like them a lot. All I meant is that because the class hierarchy differs, some of the operations not only have different names, but also they have different types. I am not particularly interested in creating an 'mtl' compatibility module, because I think it will create confusion (the libraries are similar enough as it is). People that want to use 'mtl' can use it directly, using 'monadLib' through an 'mtl' compatibility mode does not buy you anything (perhaps the WriterT in 'monadLib' is faster, but I am not sure how big of a deal that is). I think the main benefit of 'monadLib' is that it has a nicer interface than 'mtl'. their programs, and once they notice that some bit of code appears a lot, than perhaps it should be added to a library. For example, I wrote very many monads before I started using monad transformers, and all the instances were the same -- very boring. These days I very rarely create instances of the monad class. So I think that I could add support for 'Typeable', but I'd rather do it when I know of some compelling examples.
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)
I can't really use the stuff until it is released, unless (I guess) I copy-and-pasted it into my library, which does not seem like the right thing to do. While I wouldn't mind the library replacing 'mtl' (this was the original idea from some time ago) I am not sure if that is feasible (backward compatibility and what not). Also I think that libraries should be used a little more before they become "standard", so far I think I am the only real user of 'monadLib'. By the way what do you mean "compatible with 6.6"? I don't have a copy of that because it is not released (and if I understand correctly will not be for some time yet). My library uses only what I consider "standard" extensions to Haskell'98 (some rank-2 poly, and multi-parameter type classes with functional dependencies). Are any of these likely to go away in 6.6? -Iavor