On 21 July 2011 11:10, Arlen Cuss
Hi cafe!
I feel a bit like I'm speaking out of turn for bringing this up -- and I'm sure it must have been brought up many times before -- but I hope there can be something fruitful had from a discussion.
In my travels I've read several people with much better grasp of Haskell than I have mention -- with a sad sigh of resignation -- that functions like liftM and return abound because some Monads don't state their fulfillment of Functor (or Applicative, but that's even more recent), and thus we can't use fmap/<$> or pure.
Well, for fmap vs liftM, you have that liftM is automatically defined for you rather than needing to make the Functor instance, so if you're quickly defining a Monad for internal use then you can just use liftM, etc. without needing to also make Functor and Applicative instances (note that AFAIK, return and pure are the same thing, in that return isn't automatically defined like liftM is). That said, stylistically speaking when I'm writing monadic code, I tend to prefer to use liftM rather than fmap as a personal preference. Note that if you're writing polymorphic Monad functions (i.e. you have "Monad m => ..." in your type signature rather than a specific Monad) then you have to use liftM and the like because we currently don't have that Monad implies Functor.
I understand a motivation might be that code would break if the former lot were removed, but surely they could shifted to the latter (and the former simply be defined as the latter). It might be a very large effort, I suppose, to comb through the standard libraries and make everything compile again, but is there something else I'm surely missing?
It would remove backwards-compatability if/when the typeclass hierarchy is fixed, and thus a lot of code would break; as such I believe that it _is_ on the table for a future version of Haskell' that will not be 100% backwards compatible with Haskell98 and Haskell2010. The big effort here would be with user code and packages, rather than standard libraries (as the former presumably has more LOC than the latter). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com