Hi Michael,
Am Mittwoch, den 18.04.2012, 19:21 +0300 schrieb Michael Snoyman:
I'm quite a novice at rewrite rules; can anyone recommend an approach
to get my rule to fire first?
I’m not an expert of rewrite rules either, but from some experimentation
and reading -dverbose-core2core (which is
On Thu, Apr 19, 2012 at 11:47 AM, Joachim Breitner
m...@joachim-breitner.de wrote:
Hi Michael,
Am Mittwoch, den 18.04.2012, 19:21 +0300 schrieb Michael Snoyman:
I'm quite a novice at rewrite rules; can anyone recommend an approach
to get my rule to fire first?
I’m not an expert of rewrite
Hi all,
Following a little thread on Reddit[1], I'm trying to add rewrite
rules to conduit to make some simple usages of `yield` more efficient.
I've pushed these changes to a branch on Github[2]. However, I'm not
able to fully optimize the following program:
import Data.Conduit
import qualified
Hi,
I have some rewrite rules set up and am finding that in the case where
my rule pattern matches to instance methods and there are more than one
of them, my rules do not fire. If they are simply taken out from being
instance methods, they match just fine. I have posted more details and a
2011/2/15 Gábor Lehel illiss...@gmail.com:
This is a semi-related question I've been meaning to ask at some
point: I suppose this also means it's not possible to write a class,
write some rules for the class, and then have the rules be applied to
every instance? (I.e. you'd have to write them
...@haskell.org] On Behalf Of Max Bolingbroke
| Sent: 15 February 2011 09:08
| To: Gábor Lehel
| Cc: Haskell Cafe
| Subject: Re: [Haskell-cafe] rewrite rules to specialize function according to
| type class?
|
| 2011/2/15 Gábor Lehel illiss...@gmail.com:
| This is a semi-related question I've been
Hello,
2011/2/15 Simon Peyton-Jones simo...@microsoft.com
but currently any pragmas in a class decl are treated as attaching to the
*default method*, not to the method selector:
Thanks for this clarification, I had wondered about this for a while. I
think it would also be nice to mention
2011/2/15 Simon Peyton-Jones simo...@microsoft.com:
but currently any pragmas in a class decl are treated as attaching to the
*default method*, not to the method selector:
I see. I didn't realise that that was what was happening. Personally I
find this a bit surprising, but I can see the
Max Bolingbroke wrote:
2011/2/15 Simon Peyton-Jones simo...@microsoft.com:
but currently any pragmas in a class decl are treated as attaching to
the *default method*, not to the method selector:
I see. I didn't realise that that was what was happening. Personally I
find this a bit
On 15 February 2011 11:23, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
I wouldn't necessarily expect this to guarantee inlining for the same
reason that the following code doesn't guarantee that foo gets rewritten
to big:
foo = bar
{-# INLINE bar #-}
bar = big
It might work with the
Max Bolingbroke wrote:
On 15 February 2011 11:23, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
I wouldn't necessarily expect this to guarantee inlining for the same
reason that the following code doesn't guarantee that foo gets rewritten
to big:
foo = bar
{-# INLINE bar #-}
bar = big
On 15 February 2011 15:12, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
Ah, but you assume that bar won't be inlined into foo first. Consider that
it is perfectly acceptable for GHC to generate this:
foo = big
{-# INLINE bar #-}
bar = big
We did ask to inline bar, after all.
Well, yes,
Max Bolingbroke wrote:
On 15 February 2011 15:12, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
Ah, but you assume that bar won't be inlined into foo first. Consider
that it is perfectly acceptable for GHC to generate this:
foo = big {-# INLINE bar #-}
bar = big
We did ask to inline bar,
On 15 February 2011 16:45, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
Only if foo has an INLINE pragma. Otherwise, GHC uses whatever RHS is
available when it wants to inline.
Ah, I see! Well yes, in that case my workaround is indeed broken in
the way you describe, and there is no way to
Max Bolingbroke wrote:
On 15 February 2011 16:45, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
Only if foo has an INLINE pragma. Otherwise, GHC uses whatever RHS is
available when it wants to inline.
Ah, I see! Well yes, in that case my workaround is indeed broken in
the way you describe,
Hi all,
I am trying to get a GHC rewrite rule that specialises a function
according to the type of the argument of the function. Does anybody know
whether it is possible to do that not with a concrete type but rather a
type class?
Consider the following example:
class A a where
toInt
On 14 February 2011 21:43, Patrick Bahr pa...@arcor.de wrote:
Am I doing something wrong or is it not possible for GHC to dispatch a rule
according to type class constraints?
As you have discovered this is not possible. You can write the rule
for as many *particular* types as you like, but you
On Tue, Feb 15, 2011 at 12:48 AM, Max Bolingbroke
batterseapo...@hotmail.com wrote:
On 14 February 2011 21:43, Patrick Bahr pa...@arcor.de wrote:
Am I doing something wrong or is it not possible for GHC to dispatch a rule
according to type class constraints?
As you have discovered this is not
Thanks for looking into this.
Your code does give me 2 firings. But not when I replace [] with
FMList. See the attached code.
Rules.hs
Description: Binary data
Sjoerd
On Jun 23, 2009, at 5:59 PM, Simon Peyton-Jones wrote:
| I have a rewrite rule as follows:
|
| {-# RULES
|
Your FMLists are defaulting to Integer, so the rule (which
specifically mentions Int) doesn't apply. Simon's code doesn't have
this problem because of the explicit signature on upto; you could do
the same by limiting singleton to Int.
-- ryan
On Wed, Jun 24, 2009 at 12:44 AM, Sjoerd
Ah, thanks.
It turns out that this works:
transform t l = error urk
but this doesn't:
transform t l = FM $ error urk
So it has something to do with the newtype FMList. They are probably
already gone when rewrite rules fire?
Sjoerd
On Jun 24, 2009, at 6:32 PM, Ryan Ingram wrote:
| I have a rewrite rule as follows:
|
| {-# RULES
| transform/transform forall (f::forall m. Monoid m = (a - m) - (b -
| m))
| (g::forall m. Monoid m = (b - m) - (c
| - m))
| (l::FMList c). transform f (transform g
| l) = transform
Hi all,
I have a rewrite rule as follows:
{-# RULES
transform/transform forall (f::forall m. Monoid m = (a - m) - (b -
m))
(g::forall m. Monoid m = (b - m) - (c
- m))
(l::FMList c). transform f (transform g
l) = transform (g.f) l
Hi Sjoerd,
I don't know the cause of the problem, but if I add this rule, it works:
{-# RULES
inline_map forall g x. map g x = transform (. g) x
-#}
maybe, for whatever reason, the 'map' is inlined too late for the
transform/transform rule to see it?
Greetings,
Daniel
On Monday 22 June
On Jun 22, 2009, at 6:38 PM, Ryan Ingram wrote:
Not 100% sure (especially without source/core), but my guess is that
the higher-rank types make the rule unlikely to fire.
Try -ddump-simpl to see the core output, and look for places where you
expect the rule to fire. I suspect you will find
Not 100% sure (especially without source/core), but my guess is that
the higher-rank types make the rule unlikely to fire.
Try -ddump-simpl to see the core output, and look for places where you
expect the rule to fire. I suspect you will find that the types of f
and g are not forall at that
Isn't this an unsound rewrite?
cycle [(0 :: Integer)..] !! 100 = 100
[(0 :: Integer) ..] !! (100 `mod` length [(0::Integer)..]) = _|_
Anyways, the reason for inlining not being done if an expression is
used more than once is that it duplicates work that you explicitly
specified should only be
On Thu, 2008-10-16 at 09:01 +0100, Ryan Ingram wrote:
Isn't this an unsound rewrite?
Yeah, hence the just for fun :)
Anyways, the reason for inlining not being done if an expression is
used more than once is that it duplicates work that you explicitly
specified should only be done once (by
On Thu, 16 Oct 2008, George Pollard wrote:
However, in the case he has written about this won't fire, since the LHS
cannot be substituted as `cycle list` is used more than once:
let rlist = cycle list
print ( rlist !! (10^9), rlist !! 0 )
I can get it to fire again if I write it like this:
Section 8.13.2 of the GHC manual[1] states:
GHC keeps trying to apply the rules as it optimises the program. For
example, consider:
let s = map f
t = map g
in
s (t xs)
The expression s (t xs) does not match the rule map/map, but GHC
will substitute for s and t, giving an
30 matches
Mail list logo
