[Haskell-cafe] AMP - how do you motivate this in teaching?

[David Menendez]

On Fri, Nov 20, 2015 at 4:31 AM, Erik Hesselink <hesselink at gmail.com> wrote:

> On 20 November 2015 at 02:30, Manuel Gómez <targen at gmail.com> wrote:
> > I haven’t found a helpful example of an Applicative that is not a Monad
> > that is practical for a lesson.
>
> There's ZipList [0], which depending on the type of audience might be
> doable. There's also Const [1], but that needs a Monoid constraint,
> and since you said you considered ((,) e) as not having an
> Applicative, which it does have with a Monoid constraint, perhaps
> Const isn't suitable to you for that reason. There are more
> interesting examples here [2].
>

An easy way to find applicative functors that are not monads is through
composition. Composing two applicative functors gives a kind of two-stage
computation, where the outer functor can affect the inner one, but can’t
depend on anything in the inner functor.

So, Compose (State s) Maybe a = s -> (Maybe a, s) will use state to create
a partial value, but whether the final value is Nothing cannot affect the
stateful part of the computation. So definitelyFail <*> modifyState will
modify the state, even though an earlier part of the computation failed.

In contrast, MaybeT (State s) a = s -> (Maybe a, s) allows communication
between the stages, so returning Nothing will abort the rest of the
computation. I.e, definitelyFail <*> modifyState will not modify the state.

If that’s too confusing for students, an example like IO (Parser a) may be
better. This cleanly separates the creation of the parser from its
execution, but giving it a monad instance would require giving the IO stage
access to the parser’s input and output.

-- 
Dave Menendez <dave at zednenem.com>
<http://www.eyrie.org/~zednenem/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/16720bf1/attachment.html>