[Haskell] ANN: monadLib 2.0

[Iavor Diatchki]

Hello,
Thanks for the feedback!  Here are my thoughts on the questions you raise...

On 3/22/06, Bulat Ziganshin <bulat.ziganshin at gmail.com> 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

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 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'.

> 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
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