>
> If you are serious about arrow optimizations, it might be worthwhile to
> modify the original preprocessor to output a richer GADT (with cases for
> things like ArrSwap) with all the information it knows, so that user code
> can experiment with optimizations.
>
> Godspeed on this interesting pr
On Thu, Apr 30, 2009 at 11:42 AM, Peter Verswyvelen wrote:
> Thanks Ross.
> Does anyone know how to tackle this? Combining GHC's builtin arrow
> processor and rewrite rules?
>
Another possibility is to make an "optimizer" arrow transformer that encodes
the rules. Eg.
data Optimize a b c where
Thanks Ross.
Does anyone know how to tackle this? Combining GHC's builtin arrow processor
and rewrite rules?
On Wed, Apr 29, 2009 at 3:43 PM, Ross Paterson wrote:
> On Wed, Apr 29, 2009 at 03:07:25PM +0200, Peter Verswyvelen wrote:
> > After doing some pragmatic tests, it seems that neither the
On Wed, Apr 29, 2009 at 03:07:25PM +0200, Peter Verswyvelen wrote:
> After doing some pragmatic tests, it seems that neither the arrow preprocessor
> nor GHC's builtin one generate / optimize to the (***) combinator.
Right, neither of them do that. It might be possible to do that using
GHC rules,
After doing some pragmatic tests, it seems that neither the arrow
preprocessor nor GHC's builtin one generate / optimize to the (***)
combinator.
For example,
p = proc (x,y) -> do
x' <- f <- x
y' <- g <- y
return (x',y')
is equivalent to
p = f *** g
But I have the impression this kind of
