Arrow Development

[Thomas Bereknyei]

Using RULES to simplify arrows in conjunction with proc-do notation doesn't
seem feasible. (If i'm wrong, please tell me). The desugarer seems to use
lambdas that can't be captured by RULES:

        (\ ds_d9Aj ->
            let! { (a_a851, b_a852) ~ _ <- ds_d9Aj } in
            ((a_a851, b_a852), ())))
     or
            (\ ds_d9Ai -> let! { (ds_d9Ag, _) ~ _ <- ds_d9Ai } in ds_d9Ag))
or
                  (\ ds_d9Ab ->
                     let! { (a_a851, b_a852) ~ _ <- ds_d9Ab } in
                     (((a_a851, b_a852), ()), ())))

The constant shuffling of the tuples in comparison to the point-free arrow
style also seems to make it harder to optimize. This change [1] is stalled
at the moment and I'm also not sure how much it would help. Would using
named functions allow one to use RULES? On the other hand, how can we
obtain a better result without the tuple overhead? Does proc notation
require it and can we obtain a better translation of proc to a point-free
style?

[1](https://phabricator.haskell.org/D72)


On Sat, Feb 21, 2015 at 5:39 AM, Ross Paterson <R.Paterson at city.ac.uk>
wrote:

> On Fri, Feb 20, 2015 at 02:58:14AM -0500, Thomas Bereknyei wrote:
> > I am looking at the proc notation de-sugar and I see results like this
> when
> > using a Free Arrow (mostly copied from [1]):
> > line2 = proc n -> do
> >   Effect getURLSum *** Effect getURLSum -< n
> >
> > Seq [Pure ] (Seq [Pure ] (Seq [Pure ] (Seq [Pure ](Par <Effect > {Effect
> } ) ) ) )
> >
> > while this is so much simpler:
> > line2 = Effect getURLSum *** Effect getURLSum
> >
> > Par <Effect > {Effect }
> >
> > Those `Seq [Pure ]` sequences come from application of (.) and I have
> noticed
> > many similar inefficiencies in the Arrow preprocessor. Eventually the
> goal
> > would be to optimize when possible, for example I started looking into
> this in
> > order to use `concurrently` for (***) when in IO.
> >
> > There was a rewrite mentioned here [2]. The deSugar/DsArrows.hs [3] looks
> > convoluted. Any progress or work needed? Or are Arrows not used much and
> not
> > worth the effort?
>
> I don't think it's feasible to try to do optimization in the desugarer,
> which certainly is convoluted.  You might have more luck using RULES to
> simplify the output.
>
> (The desugarer could be simplified -- a lot of what it does probably
> belongs
> in the renamer -- but I'm not sure that would help with optimization.)
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150224/6cad58c0/attachment.html>