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? [1] http://stackoverflow.com/questions/12001350/useful-operations-on-free-arrows [2]https://mail.haskell.org/pipermail/haskell-cafe/2013-August/109795.html [3]https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsArrows.hs -Tom
There was a rewrite mentioned here [2]. The deSugar/DsArrows.hs [3] looks convoluted. Any progress or work needed? Take a look at #7828 ticket. There was an intention to rewrite arrow desugarer and I worked on it for some time but eventually abandoned it. Sophie Taylor was planning to take up that work but I don't think she did (or at least she's been quiet for the past few months).
Or are Arrows not used much and not worth the effort? There are several open tickets about arrows (#5267, #5333, #5777, #344 and of course #7828) but at the moment it seems that no one really complains about these. If you use arrows and have a good idea how they work then perhaps you could fix these bugs?
Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.
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.)
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
participants (3)
-
Jan Stolarek -
Ross Paterson -
Thomas Bereknyei