[Haskell-cafe] Fwd: Smarter do notation
Alberto G. Corona
agocorona at gmail.com
Mon Sep 5 17:31:20 CEST 2011
---------- Forwarded message ----------
From: Alberto G. Corona <agocorona at gmail.com>
Date: 2011/9/5
Subject: Re: [Haskell-cafe] Smarter do notation
To: Sebastian Fischer <fischer at nii.ac.jp>
Cc: Max Bolingbroke <batterseapower at hotmail.com>, haskell-cafe at haskell.org
The problem in the parallel distribution of monadic computations that may
have been Applicative seems to be the >> operator
But if Monad is defined as a subclass of applicative:
http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal
then ">>" can be defined as (>>) = (*>) and parallelization should be
pòssible ?
Alberto
2011/9/5 Sebastian Fischer <fischer at nii.ac.jp>
> Hi again,
>
> I think the following rules capture what Max's program does if applied
> after the usual desugaring of do-notation:
>
> a >>= \p -> return b
> -->
> (\p -> b) <$> a
>
> a >>= \p -> f <$> b -- 'free p' and 'free b' disjoint
> -->
> ((\p -> f) <$> a) <*> b
>
> a >>= \p -> f <$> b -- 'free p' and 'free f' disjoint
> -->
> f <$> (a >>= \p -> b)
>
> a >>= \p -> b <*> c -- 'free p' and 'free c' disjoint
> -->
> (a >>= \p -> b) <*> c
>
> a >>= \p -> b >>= \q -> c -- 'free p' and 'free b' disjoint
> -->
> liftA2 (,) a b >>= \(p,q) -> c
>
> a >>= \p -> b >> c -- 'free p' and 'free b' disjoint
> -->
> (a << b) >>= \p -> c
>
> The second and third rule overlap and should be applied in this order.
> 'free' gives all free variables of a pattern 'p' or an expression
> 'a','b','c', or 'f'.
>
> If return, >>, and << are defined in Applicative, I think the rules also
> achieve the minimal necessary class constraint for Thomas's examples that do
> not involve aliasing of return.
>
> Sebastian
>
> On Mon, Sep 5, 2011 at 5:37 PM, Sebastian Fischer <fischer at nii.ac.jp>wrote:
>
>> Hi Max,
>>
>> thanks for you proposal!
>>
>> Using the Applicative methods to optimise "do" desugaring is still
>>> possible, it's just not that easy to have that weaken the generated
>>> constraint from Monad to Applicative since only degenerate programs
>>> like this one won't use a Monad method:
>>>
>>
>> Is this still true, once Monad is a subclass of Applicative which defines
>> return?
>>
>> I'd still somewhat prefer if return get's merged with the preceding
>> statement so sometimes only a Functor constraint is generated but I think, I
>> should adjust your desugaring then..
>>
>> Sebastian
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110905/a68e7850/attachment.htm>
More information about the Haskell-Cafe
mailing list