Is `x >> pure y` equivalent to `liftM (const y) x` Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern) Data science time! April 2019 and salary with experience The Ask Question Wizard is Live!Unlike a Functor, a Monad can change shape?Why should Applicative be a superclass of Monad?Is there a monad that doesn't have a corresponding monad transformer (except IO)?Composition of compositions in HaskellHaskell: Flaw in the description of applicative functor laws in the hackage Control.Applicative article?: it says Applicative determines FunctorTo what extent are Applicative/Monad instances uniquely determined?Is this property of a functor stronger than a monad?Are applicative functors composed with the applicative style really independent?bind can be composed of fmap and join, so do we have to use monadic functions a -> m b?Do the monadic liftM and the functorial fmap have to be equivalent?

Putting class ranking in CV, but against dept guidelines

Hangman Game with C++

How do I find out the mythology and history of my Fortress?

When a candle burns, why does the top of wick glow if bottom of flame is hottest?

How to make a Field only accept Numbers in Magento 2

What initially awakened the Balrog?

Belief In God or Knowledge Of God. Which is better?

Is CEO the "profession" with the most psychopaths?

Why limits give us the exact value of the slope of the tangent line?

How were pictures turned from film to a big picture in a picture frame before digital scanning?

Why weren't discrete x86 CPUs ever used in game hardware?

Can a new player join a group only when a new campaign starts?

Can anything be seen from the center of the Boötes void? How dark would it be?

Crossing US/Canada Border for less than 24 hours

Put R under double integral

How would a mousetrap for use in space work?

Maximum summed subsequences with non-adjacent items

Sum letters are not two different

Why is it faster to reheat something than it is to cook it?

How does light 'choose' between wave and particle behaviour?

If Windows 7 doesn't support WSL, then what does Linux subsystem option mean?

Aligning an equation at multiple points, with both left and right alignment, as well as equals sign alignment

Lagrange four-squares theorem --- deterministic complexity

How to unroll a parameter pack from right to left



Is `x >> pure y` equivalent to `liftM (const y) x`



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern)
Data science time! April 2019 and salary with experience
The Ask Question Wizard is Live!Unlike a Functor, a Monad can change shape?Why should Applicative be a superclass of Monad?Is there a monad that doesn't have a corresponding monad transformer (except IO)?Composition of compositions in HaskellHaskell: Flaw in the description of applicative functor laws in the hackage Control.Applicative article?: it says Applicative determines FunctorTo what extent are Applicative/Monad instances uniquely determined?Is this property of a functor stronger than a monad?Are applicative functors composed with the applicative style really independent?bind can be composed of fmap and join, so do we have to use monadic functions a -> m b?Do the monadic liftM and the functorial fmap have to be equivalent?



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








15















The two expressions



y >> pure x
liftM (const x) y


have the same type signature in Haskell.
I was curious whether they were equivalent, but I could neither produce a proof of the fact nor a counter example against it.



If we rewrite the two expressions so that we can eliminate the x and y then the question becomes whether the two following functions are equivalent



flip (>>) . pure
liftM . const


Note that both these functions have type Monad m => a -> m b -> m a.



I used the laws that Haskell gives for monad, applicatives, and functors to transform both statements into various equivalent forms, but I was not able to produce a sequence of equivalences between the two.



For instance I found that y >> pure x can be rewritten as follows



y >>= const (pure x)
y *> pure x
(id <$ y) <*> pure x
fmap (const id) y <*> pure x


and liftM (const x) y can be rewritten as follows



fmap (const x) y
pure (const x) <*> y


None of these spring out to me as necessarily equivalent, but I cannot think of any cases where they would not be equivalent.










share|improve this question






























    15















    The two expressions



    y >> pure x
    liftM (const x) y


    have the same type signature in Haskell.
    I was curious whether they were equivalent, but I could neither produce a proof of the fact nor a counter example against it.



    If we rewrite the two expressions so that we can eliminate the x and y then the question becomes whether the two following functions are equivalent



    flip (>>) . pure
    liftM . const


    Note that both these functions have type Monad m => a -> m b -> m a.



    I used the laws that Haskell gives for monad, applicatives, and functors to transform both statements into various equivalent forms, but I was not able to produce a sequence of equivalences between the two.



    For instance I found that y >> pure x can be rewritten as follows



    y >>= const (pure x)
    y *> pure x
    (id <$ y) <*> pure x
    fmap (const id) y <*> pure x


    and liftM (const x) y can be rewritten as follows



    fmap (const x) y
    pure (const x) <*> y


    None of these spring out to me as necessarily equivalent, but I cannot think of any cases where they would not be equivalent.










    share|improve this question


























      15












      15








      15








      The two expressions



      y >> pure x
      liftM (const x) y


      have the same type signature in Haskell.
      I was curious whether they were equivalent, but I could neither produce a proof of the fact nor a counter example against it.



      If we rewrite the two expressions so that we can eliminate the x and y then the question becomes whether the two following functions are equivalent



      flip (>>) . pure
      liftM . const


      Note that both these functions have type Monad m => a -> m b -> m a.



      I used the laws that Haskell gives for monad, applicatives, and functors to transform both statements into various equivalent forms, but I was not able to produce a sequence of equivalences between the two.



      For instance I found that y >> pure x can be rewritten as follows



      y >>= const (pure x)
      y *> pure x
      (id <$ y) <*> pure x
      fmap (const id) y <*> pure x


      and liftM (const x) y can be rewritten as follows



      fmap (const x) y
      pure (const x) <*> y


      None of these spring out to me as necessarily equivalent, but I cannot think of any cases where they would not be equivalent.










      share|improve this question
















      The two expressions



      y >> pure x
      liftM (const x) y


      have the same type signature in Haskell.
      I was curious whether they were equivalent, but I could neither produce a proof of the fact nor a counter example against it.



      If we rewrite the two expressions so that we can eliminate the x and y then the question becomes whether the two following functions are equivalent



      flip (>>) . pure
      liftM . const


      Note that both these functions have type Monad m => a -> m b -> m a.



      I used the laws that Haskell gives for monad, applicatives, and functors to transform both statements into various equivalent forms, but I was not able to produce a sequence of equivalences between the two.



      For instance I found that y >> pure x can be rewritten as follows



      y >>= const (pure x)
      y *> pure x
      (id <$ y) <*> pure x
      fmap (const id) y <*> pure x


      and liftM (const x) y can be rewritten as follows



      fmap (const x) y
      pure (const x) <*> y


      None of these spring out to me as necessarily equivalent, but I cannot think of any cases where they would not be equivalent.







      haskell monads functor applicative






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Mar 27 at 20:30









      duplode

      23.5k44990




      23.5k44990










      asked Mar 27 at 18:31









      10000000001000000000

      489214




      489214






















          3 Answers
          3






          active

          oldest

          votes


















          15














          The other answer gets there eventually, but it takes a long-winded route. All that is actually needed are the definitions of liftM, const, and a single monad law: m1 >> m2 and m1 >>= _ -> m2 must be semantically identical. (Indeed, this is the default implementation of (>>), and it is rare to override it.) Then:



          liftM (const x) y
          = definition of liftM*
          y >>= z -> pure (const x z)
          = definition of const
          y >>= z -> pure x
          = monad law
          y >> pure x


          * Okay, okay, so the actual definition of liftM uses return instead of pure. Whatever.






          share|improve this answer

























          • Interesting. For some reason I thought that the standard definition was liftM = fmap, with the more restrictive type. With the real definition above, the wanted equation is much simpler to obtain :)

            – chi
            Mar 27 at 20:00






          • 1





            @chi Even without it things aren't too bad: fmap f m = m >>= return . f is also a monad law (one of the oft-forgotten ones).

            – Daniel Wagner
            Mar 27 at 20:47







          • 5





            That law itself follows from parametricity and the monad law m >>= pure = m.

            – dfeuer
            Mar 27 at 21:27


















          12














          Yes they are the same



          Let's start with flip (>>) . pure, which is the pointfree version of x >> pure y you provide:



          flip (>>) . pure


          It is the case that flip (>>) is just (=<<) . const so we can rewrite this as:



          ((=<<) . const) . pure


          Since function composition ((.)) is associative we can write this as:



          (=<<) . (const . pure)


          Now we would like to rewrite const . pure. We can notice that const is just pure on (a ->), that means since pure . pure is fmap pure . pure, const . pure is (.) pure . const, ((.) is fmap for the functor (a ->)).



          (=<<) . ((.) pure . const)


          Now we associate again:



          ((=<<) . (.) pure) . const


          ((=<<) . (.) pure) is the definition for liftM1 so we can substitute:



          liftM . const


          And that is the goal. The two are the same.




          1: The definition of liftM is liftM f m1 = do x1 <- m1; return (f x1) , we can desugar the do into liftM f m1 = m1 >>= return . f. We can flip the (>>=) for liftM f m1 = return . f =<< m1 and elide the m1 to get liftM f = (return . f =<<) a little pointfree magic and we get liftM = (=<<) . (.) return






          share|improve this answer




















          • 1





            Can you please add how you get from const . pure to fmap pure . const? Btw it might have been easier to start with (.) right away instead of writing fmap (and later explaining (figuring out?) what Functor instance it belongs to).

            – Bergi
            Mar 27 at 22:30







          • 1





            @Bergi Actually you are right, doing it earlier makes things simpler.

            – Sriotchilism O'Zaic
            Mar 27 at 22:54


















          4














          One more possible route, exploiting the applicative laws:




          For instance I found that y >> pure x can be rewritten as follows [...]



          fmap (const id) y <*> pure x



          That amounts to...



          fmap (const id) y <*> pure x
          pure ($ x) <*> fmap (const id) y -- interchange law of applicatives
          fmap ($ x) (fmap (const id) y) -- fmap in terms of <*>
          fmap (($ x) . const id) y -- composition law of functors
          fmap (const x) y


          ... which, as you noted, is the same as liftM (const x) y.



          That this route requires only applicative laws and not monad ones reflects how (*>) (another name for (>>)) is an Applicative method.






          share|improve this answer

























            Your Answer






            StackExchange.ifUsing("editor", function ()
            StackExchange.using("externalEditor", function ()
            StackExchange.using("snippets", function ()
            StackExchange.snippets.init();
            );
            );
            , "code-snippets");

            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "1"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55384267%2fis-x-pure-y-equivalent-to-liftm-const-y-x%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            15














            The other answer gets there eventually, but it takes a long-winded route. All that is actually needed are the definitions of liftM, const, and a single monad law: m1 >> m2 and m1 >>= _ -> m2 must be semantically identical. (Indeed, this is the default implementation of (>>), and it is rare to override it.) Then:



            liftM (const x) y
            = definition of liftM*
            y >>= z -> pure (const x z)
            = definition of const
            y >>= z -> pure x
            = monad law
            y >> pure x


            * Okay, okay, so the actual definition of liftM uses return instead of pure. Whatever.






            share|improve this answer

























            • Interesting. For some reason I thought that the standard definition was liftM = fmap, with the more restrictive type. With the real definition above, the wanted equation is much simpler to obtain :)

              – chi
              Mar 27 at 20:00






            • 1





              @chi Even without it things aren't too bad: fmap f m = m >>= return . f is also a monad law (one of the oft-forgotten ones).

              – Daniel Wagner
              Mar 27 at 20:47







            • 5





              That law itself follows from parametricity and the monad law m >>= pure = m.

              – dfeuer
              Mar 27 at 21:27















            15














            The other answer gets there eventually, but it takes a long-winded route. All that is actually needed are the definitions of liftM, const, and a single monad law: m1 >> m2 and m1 >>= _ -> m2 must be semantically identical. (Indeed, this is the default implementation of (>>), and it is rare to override it.) Then:



            liftM (const x) y
            = definition of liftM*
            y >>= z -> pure (const x z)
            = definition of const
            y >>= z -> pure x
            = monad law
            y >> pure x


            * Okay, okay, so the actual definition of liftM uses return instead of pure. Whatever.






            share|improve this answer

























            • Interesting. For some reason I thought that the standard definition was liftM = fmap, with the more restrictive type. With the real definition above, the wanted equation is much simpler to obtain :)

              – chi
              Mar 27 at 20:00






            • 1





              @chi Even without it things aren't too bad: fmap f m = m >>= return . f is also a monad law (one of the oft-forgotten ones).

              – Daniel Wagner
              Mar 27 at 20:47







            • 5





              That law itself follows from parametricity and the monad law m >>= pure = m.

              – dfeuer
              Mar 27 at 21:27













            15












            15








            15







            The other answer gets there eventually, but it takes a long-winded route. All that is actually needed are the definitions of liftM, const, and a single monad law: m1 >> m2 and m1 >>= _ -> m2 must be semantically identical. (Indeed, this is the default implementation of (>>), and it is rare to override it.) Then:



            liftM (const x) y
            = definition of liftM*
            y >>= z -> pure (const x z)
            = definition of const
            y >>= z -> pure x
            = monad law
            y >> pure x


            * Okay, okay, so the actual definition of liftM uses return instead of pure. Whatever.






            share|improve this answer















            The other answer gets there eventually, but it takes a long-winded route. All that is actually needed are the definitions of liftM, const, and a single monad law: m1 >> m2 and m1 >>= _ -> m2 must be semantically identical. (Indeed, this is the default implementation of (>>), and it is rare to override it.) Then:



            liftM (const x) y
            = definition of liftM*
            y >>= z -> pure (const x z)
            = definition of const
            y >>= z -> pure x
            = monad law
            y >> pure x


            * Okay, okay, so the actual definition of liftM uses return instead of pure. Whatever.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 27 at 18:59

























            answered Mar 27 at 18:54









            Daniel WagnerDaniel Wagner

            104k7162287




            104k7162287












            • Interesting. For some reason I thought that the standard definition was liftM = fmap, with the more restrictive type. With the real definition above, the wanted equation is much simpler to obtain :)

              – chi
              Mar 27 at 20:00






            • 1





              @chi Even without it things aren't too bad: fmap f m = m >>= return . f is also a monad law (one of the oft-forgotten ones).

              – Daniel Wagner
              Mar 27 at 20:47







            • 5





              That law itself follows from parametricity and the monad law m >>= pure = m.

              – dfeuer
              Mar 27 at 21:27

















            • Interesting. For some reason I thought that the standard definition was liftM = fmap, with the more restrictive type. With the real definition above, the wanted equation is much simpler to obtain :)

              – chi
              Mar 27 at 20:00






            • 1





              @chi Even without it things aren't too bad: fmap f m = m >>= return . f is also a monad law (one of the oft-forgotten ones).

              – Daniel Wagner
              Mar 27 at 20:47







            • 5





              That law itself follows from parametricity and the monad law m >>= pure = m.

              – dfeuer
              Mar 27 at 21:27
















            Interesting. For some reason I thought that the standard definition was liftM = fmap, with the more restrictive type. With the real definition above, the wanted equation is much simpler to obtain :)

            – chi
            Mar 27 at 20:00





            Interesting. For some reason I thought that the standard definition was liftM = fmap, with the more restrictive type. With the real definition above, the wanted equation is much simpler to obtain :)

            – chi
            Mar 27 at 20:00




            1




            1





            @chi Even without it things aren't too bad: fmap f m = m >>= return . f is also a monad law (one of the oft-forgotten ones).

            – Daniel Wagner
            Mar 27 at 20:47






            @chi Even without it things aren't too bad: fmap f m = m >>= return . f is also a monad law (one of the oft-forgotten ones).

            – Daniel Wagner
            Mar 27 at 20:47





            5




            5





            That law itself follows from parametricity and the monad law m >>= pure = m.

            – dfeuer
            Mar 27 at 21:27





            That law itself follows from parametricity and the monad law m >>= pure = m.

            – dfeuer
            Mar 27 at 21:27













            12














            Yes they are the same



            Let's start with flip (>>) . pure, which is the pointfree version of x >> pure y you provide:



            flip (>>) . pure


            It is the case that flip (>>) is just (=<<) . const so we can rewrite this as:



            ((=<<) . const) . pure


            Since function composition ((.)) is associative we can write this as:



            (=<<) . (const . pure)


            Now we would like to rewrite const . pure. We can notice that const is just pure on (a ->), that means since pure . pure is fmap pure . pure, const . pure is (.) pure . const, ((.) is fmap for the functor (a ->)).



            (=<<) . ((.) pure . const)


            Now we associate again:



            ((=<<) . (.) pure) . const


            ((=<<) . (.) pure) is the definition for liftM1 so we can substitute:



            liftM . const


            And that is the goal. The two are the same.




            1: The definition of liftM is liftM f m1 = do x1 <- m1; return (f x1) , we can desugar the do into liftM f m1 = m1 >>= return . f. We can flip the (>>=) for liftM f m1 = return . f =<< m1 and elide the m1 to get liftM f = (return . f =<<) a little pointfree magic and we get liftM = (=<<) . (.) return






            share|improve this answer




















            • 1





              Can you please add how you get from const . pure to fmap pure . const? Btw it might have been easier to start with (.) right away instead of writing fmap (and later explaining (figuring out?) what Functor instance it belongs to).

              – Bergi
              Mar 27 at 22:30







            • 1





              @Bergi Actually you are right, doing it earlier makes things simpler.

              – Sriotchilism O'Zaic
              Mar 27 at 22:54















            12














            Yes they are the same



            Let's start with flip (>>) . pure, which is the pointfree version of x >> pure y you provide:



            flip (>>) . pure


            It is the case that flip (>>) is just (=<<) . const so we can rewrite this as:



            ((=<<) . const) . pure


            Since function composition ((.)) is associative we can write this as:



            (=<<) . (const . pure)


            Now we would like to rewrite const . pure. We can notice that const is just pure on (a ->), that means since pure . pure is fmap pure . pure, const . pure is (.) pure . const, ((.) is fmap for the functor (a ->)).



            (=<<) . ((.) pure . const)


            Now we associate again:



            ((=<<) . (.) pure) . const


            ((=<<) . (.) pure) is the definition for liftM1 so we can substitute:



            liftM . const


            And that is the goal. The two are the same.




            1: The definition of liftM is liftM f m1 = do x1 <- m1; return (f x1) , we can desugar the do into liftM f m1 = m1 >>= return . f. We can flip the (>>=) for liftM f m1 = return . f =<< m1 and elide the m1 to get liftM f = (return . f =<<) a little pointfree magic and we get liftM = (=<<) . (.) return






            share|improve this answer




















            • 1





              Can you please add how you get from const . pure to fmap pure . const? Btw it might have been easier to start with (.) right away instead of writing fmap (and later explaining (figuring out?) what Functor instance it belongs to).

              – Bergi
              Mar 27 at 22:30







            • 1





              @Bergi Actually you are right, doing it earlier makes things simpler.

              – Sriotchilism O'Zaic
              Mar 27 at 22:54













            12












            12








            12







            Yes they are the same



            Let's start with flip (>>) . pure, which is the pointfree version of x >> pure y you provide:



            flip (>>) . pure


            It is the case that flip (>>) is just (=<<) . const so we can rewrite this as:



            ((=<<) . const) . pure


            Since function composition ((.)) is associative we can write this as:



            (=<<) . (const . pure)


            Now we would like to rewrite const . pure. We can notice that const is just pure on (a ->), that means since pure . pure is fmap pure . pure, const . pure is (.) pure . const, ((.) is fmap for the functor (a ->)).



            (=<<) . ((.) pure . const)


            Now we associate again:



            ((=<<) . (.) pure) . const


            ((=<<) . (.) pure) is the definition for liftM1 so we can substitute:



            liftM . const


            And that is the goal. The two are the same.




            1: The definition of liftM is liftM f m1 = do x1 <- m1; return (f x1) , we can desugar the do into liftM f m1 = m1 >>= return . f. We can flip the (>>=) for liftM f m1 = return . f =<< m1 and elide the m1 to get liftM f = (return . f =<<) a little pointfree magic and we get liftM = (=<<) . (.) return






            share|improve this answer















            Yes they are the same



            Let's start with flip (>>) . pure, which is the pointfree version of x >> pure y you provide:



            flip (>>) . pure


            It is the case that flip (>>) is just (=<<) . const so we can rewrite this as:



            ((=<<) . const) . pure


            Since function composition ((.)) is associative we can write this as:



            (=<<) . (const . pure)


            Now we would like to rewrite const . pure. We can notice that const is just pure on (a ->), that means since pure . pure is fmap pure . pure, const . pure is (.) pure . const, ((.) is fmap for the functor (a ->)).



            (=<<) . ((.) pure . const)


            Now we associate again:



            ((=<<) . (.) pure) . const


            ((=<<) . (.) pure) is the definition for liftM1 so we can substitute:



            liftM . const


            And that is the goal. The two are the same.




            1: The definition of liftM is liftM f m1 = do x1 <- m1; return (f x1) , we can desugar the do into liftM f m1 = m1 >>= return . f. We can flip the (>>=) for liftM f m1 = return . f =<< m1 and elide the m1 to get liftM f = (return . f =<<) a little pointfree magic and we get liftM = (=<<) . (.) return







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 27 at 22:54

























            answered Mar 27 at 18:31









            Sriotchilism O'ZaicSriotchilism O'Zaic

            863620




            863620







            • 1





              Can you please add how you get from const . pure to fmap pure . const? Btw it might have been easier to start with (.) right away instead of writing fmap (and later explaining (figuring out?) what Functor instance it belongs to).

              – Bergi
              Mar 27 at 22:30







            • 1





              @Bergi Actually you are right, doing it earlier makes things simpler.

              – Sriotchilism O'Zaic
              Mar 27 at 22:54












            • 1





              Can you please add how you get from const . pure to fmap pure . const? Btw it might have been easier to start with (.) right away instead of writing fmap (and later explaining (figuring out?) what Functor instance it belongs to).

              – Bergi
              Mar 27 at 22:30







            • 1





              @Bergi Actually you are right, doing it earlier makes things simpler.

              – Sriotchilism O'Zaic
              Mar 27 at 22:54







            1




            1





            Can you please add how you get from const . pure to fmap pure . const? Btw it might have been easier to start with (.) right away instead of writing fmap (and later explaining (figuring out?) what Functor instance it belongs to).

            – Bergi
            Mar 27 at 22:30






            Can you please add how you get from const . pure to fmap pure . const? Btw it might have been easier to start with (.) right away instead of writing fmap (and later explaining (figuring out?) what Functor instance it belongs to).

            – Bergi
            Mar 27 at 22:30





            1




            1





            @Bergi Actually you are right, doing it earlier makes things simpler.

            – Sriotchilism O'Zaic
            Mar 27 at 22:54





            @Bergi Actually you are right, doing it earlier makes things simpler.

            – Sriotchilism O'Zaic
            Mar 27 at 22:54











            4














            One more possible route, exploiting the applicative laws:




            For instance I found that y >> pure x can be rewritten as follows [...]



            fmap (const id) y <*> pure x



            That amounts to...



            fmap (const id) y <*> pure x
            pure ($ x) <*> fmap (const id) y -- interchange law of applicatives
            fmap ($ x) (fmap (const id) y) -- fmap in terms of <*>
            fmap (($ x) . const id) y -- composition law of functors
            fmap (const x) y


            ... which, as you noted, is the same as liftM (const x) y.



            That this route requires only applicative laws and not monad ones reflects how (*>) (another name for (>>)) is an Applicative method.






            share|improve this answer





























              4














              One more possible route, exploiting the applicative laws:




              For instance I found that y >> pure x can be rewritten as follows [...]



              fmap (const id) y <*> pure x



              That amounts to...



              fmap (const id) y <*> pure x
              pure ($ x) <*> fmap (const id) y -- interchange law of applicatives
              fmap ($ x) (fmap (const id) y) -- fmap in terms of <*>
              fmap (($ x) . const id) y -- composition law of functors
              fmap (const x) y


              ... which, as you noted, is the same as liftM (const x) y.



              That this route requires only applicative laws and not monad ones reflects how (*>) (another name for (>>)) is an Applicative method.






              share|improve this answer



























                4












                4








                4







                One more possible route, exploiting the applicative laws:




                For instance I found that y >> pure x can be rewritten as follows [...]



                fmap (const id) y <*> pure x



                That amounts to...



                fmap (const id) y <*> pure x
                pure ($ x) <*> fmap (const id) y -- interchange law of applicatives
                fmap ($ x) (fmap (const id) y) -- fmap in terms of <*>
                fmap (($ x) . const id) y -- composition law of functors
                fmap (const x) y


                ... which, as you noted, is the same as liftM (const x) y.



                That this route requires only applicative laws and not monad ones reflects how (*>) (another name for (>>)) is an Applicative method.






                share|improve this answer















                One more possible route, exploiting the applicative laws:




                For instance I found that y >> pure x can be rewritten as follows [...]



                fmap (const id) y <*> pure x



                That amounts to...



                fmap (const id) y <*> pure x
                pure ($ x) <*> fmap (const id) y -- interchange law of applicatives
                fmap ($ x) (fmap (const id) y) -- fmap in terms of <*>
                fmap (($ x) . const id) y -- composition law of functors
                fmap (const x) y


                ... which, as you noted, is the same as liftM (const x) y.



                That this route requires only applicative laws and not monad ones reflects how (*>) (another name for (>>)) is an Applicative method.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Mar 27 at 22:37

























                answered Mar 27 at 20:27









                duplodeduplode

                23.5k44990




                23.5k44990



























                    draft saved

                    draft discarded
















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55384267%2fis-x-pure-y-equivalent-to-liftm-const-y-x%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Lowndes Grove History Architecture References Navigation menu32°48′6″N 79°57′58″W / 32.80167°N 79.96611°W / 32.80167; -79.9661132°48′6″N 79°57′58″W / 32.80167°N 79.96611°W / 32.80167; -79.9661178002500"National Register Information System"Historic houses of South Carolina"Lowndes Grove""+32° 48' 6.00", −79° 57' 58.00""Lowndes Grove, Charleston County (260 St. Margaret St., Charleston)""Lowndes Grove"The Charleston ExpositionIt Happened in South Carolina"Lowndes Grove (House), Saint Margaret Street & Sixth Avenue, Charleston, Charleston County, SC(Photographs)"Plantations of the Carolina Low Countrye

                    How should I support this large drywall patch? Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?How do I cover large gaps in drywall?How do I keep drywall around a patch from crumbling?Can I glue a second layer of drywall?How to patch long strip on drywall?Large drywall patch: how to avoid bulging seams?Drywall Mesh Patch vs. Bulge? To remove or not to remove?How to fix this drywall job?Prep drywall before backsplashWhat's the best way to fix this horrible drywall patch job?Drywall patching using 3M Patch Plus Primer

                    random experiment with two different functions on unit interval Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern)Random variable and probability space notionsRandom Walk with EdgesFinding functions where the increase over a random interval is Poisson distributedNumber of days until dayCan an observed event in fact be of zero probability?Unit random processmodels of coins and uniform distributionHow to get the number of successes given $n$ trials , probability $P$ and a random variable $X$Absorbing Markov chain in a computer. Is “almost every” turned into always convergence in computer executions?Stopped random walk is not uniformly integrable