On Mon, Nov 30, 2009 at 6:50 PM, Ross Paterson <span dir="ltr"><<a href="mailto:ross@soi.city.ac.uk">ross@soi.city.ac.uk</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sun, Nov 29, 2009 at 07:29:47PM -0500, Edward Kmett wrote:<br>
> The final issue is whether or not it is a good idea to eliminate the<br>
> simpler non-transformer versions of the monads.<br>
><br>
> Without them, libraries that provide instances for the various monads<br>
> cannot provide instances for State and StateT in a way that lets them<br>
> work compatibly with both versions.<br>
><br>
> So, an issue that I would like to talk about separately is if we<br>
> _should_ be dropping the basic State, Reader, Writer, etc. constructors.<br>
> They have definite pedagogical value, and have easier to understand<br>
> behavior for introductory purposes. If we kept those then ALL code<br>
> that worked with mtl 1.2 would be compatible with mtl 2, which strikes<br>
> me as a desirable property. This has the benefit that it is easier<br>
> to write libraries that export instances. I think we would be remiss<br>
> in not at least considering the issue. On the other hand, I don't<br>
> know how many libraries provide instances for the monads in the MTL.<br>
> I have a few in my monoids library, but I'd be willing to go either way.<br>
<br>
</div>The benefit of defining these as type synonyms is that the Haskell 98<br>
transformers package has the same functions operating on both the base<br>
monad and the corresponding transformer; there is no need to define two<br>
versions of everything. Similarly fewer instances are required in the<br>
monad class packages.<br></blockquote><div><br></div><div>True. Like I said, I'd be happy with either way.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I think the pedagogical issue can be handled in other ways, and that<br>
making compatibility with the current mtl an overriding requirement<br>
would be unduly constraining. In any case there would be no complete<br>
compatibility, as transformers adds Applicative and Alternative instances,<br>
and also changes the constraints on Functor instances.<br></blockquote><div><br></div><div>I agree that perfect backwards compatibility is impossible. That said, unlike the type aliases, these are all cases where something new would work that didn't previously. Library code that wanted to be backwards compatible could avoid using the new instances, and the more permissive Functor instances shouldn't break any code that worked before unless that code was defining its own local version of Applicative, Alternative, etc. which were constrained by the restrictive Functor definitions to not work in the most permissive form anyway, so where needed, library code could work around using WrappedMonad, etc. in a way that would be compatible.</div>
<div><br></div><div>It is true, that it would constrain the design of the mtl to carry a handful of handy (or burdensome, depending on your perspective) tutorial constructors around, but note that the functions themselves for working with the simpler type are still contained in transformers, so the function count doesn't really change either way. But the other way says that all of the libraries that re-export functionality on top of the mtl must discard coverage of the non-transformer case when linked against the old mtl.</div>
<div><br></div><div>Both options suck, but only one provides no way out except to force someone up to the new version that they may not be able to use because of other package requirements. I have yet to see any major migration to a new version of a library that isn't more or less plug in compatible with the old version actually take hold (witness current adoption levels of parsec 3 & quickcheck 2). </div>
<div><br></div><div>I hope this doesn't across as too cynical. I just figured that someone should play devil's advocate, before things got drowned in a sea of +1s.</div><div><br></div><div>-Edward Kmett</div><div>
<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br>