Le Tue, 16 Oct 2012 07:35:34 +0530, damodar kulkarni <kdamodar2...@gmail.com> a écrit :
> @Jake > > In my opinion, this is not as nice as the do-notation version, but at > > least it's compositional: > > > That's an important point you have made, as Haskellers value code > composition so much. > If code composition is the "holy grail", why not encourage the monadic > code, too, to be compositional? Nicety can wait; some syntax sugar > might take care of it. > > And as you have pointed out, arrows make a superior choice in this > regard, but they are rather newer to monads. > > @ AUGER Cédric > > It would be rather awful to expand each of your Kleisli arrows with > > > "const" as you said. > > > > The const is required in this example because we are dealing with > getLine (as getLine can return different strings at different times > without taking any argument). Again, some syntactic sugar would have > taken care of this "const" thing. > > Correct me if I am wrong. We were not dealing with getLine in particular. The point was about knowing if >>= could be defined in terms of >=>. The const is necessary for the general case. So I think that an implicit question was why wouldn't we have: class Monad m where return :: a -> m a kleisli :: (a -> m b) -> (b -> m c) -> (a -> m c) bind = \ x f -> ((const x) >=> f) () join = id>=>id :: (m (m a) -> m a) (Sorry, I do not remember the correct Haskell syntax, I am a beginner, but I do not have touched the language for some time…) That is "bind" would have a default construction (like "join" has got its one now). The definition of "join" would become rather nice this way ^^ Not redefining the "join" and "bind" function would lead to expand them with "\ x f -> (const x) >=> f" and "id>=>id", that is what I meant, and found it awful for "bind". Of course I do not say that Kleisli is a bad idea. I even think it is better to use it when you want composition, or you want to do the initial given example (readString >=> putString, or something like that, I do not really remember). But I do not think defining Monads from Kleisli (or T-algebras, for the other adjunction construction) would be very nice. On the other hand, I guess that the class Monad could contain the definition of Kleisli arrows. But as we have instances ArrowApply a => Monad (ArrowMonad a) and Monad m => Arrow (Kleisli m), I do not think we lack some functionnality. > > and thanks for responses. > > Damodar > > On Mon, Oct 15, 2012 at 9:09 PM, Jake McArthur > <jake.mcart...@gmail.com>wrote: > > > On Mon, Oct 15, 2012 at 11:33 AM, Jake McArthur > > <jake.mcart...@gmail.com> wrote: > > > On Mon, Oct 15, 2012 at 7:59 AM, Ertugrul Söylemez <e...@ertes.de> > > > wrote: > > >> Try to express > > >> > > >> do x <- getLine > > >> y <- getLine > > >> print (x, y) > > >> > > >> using only Kleisli composition (without cheating). > > > > My previous answer didn't do the Kleisli style much justice. It > > could look a bit nicer with more Arrow-style combinators: > > > > f &=& g = runKleisli $ Kleisli f &&& Kleisli g > > > > print <=< const getLine &=& const getLine $ () > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe