[Haskell] ANN: monadLib 2.0

[Bulat Ziganshin]

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 at gmail.com