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@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs