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
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
On Fri, Feb 20, 2015 at 02:58:14AM -0500, Thomas Bereknyei wrote: 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