On Thu, Apr 19, 2012 at 11:47 AM, Joachim Breitner
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 rules either, but
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
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
co
Max Bolingbroke wrote:
> On 15 February 2011 16:45, Roman Leshchinskiy 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 i
On 15 February 2011 16:45, Roman Leshchinskiy 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 repair it because in m
Max Bolingbroke wrote:
> On 15 February 2011 15:12, Roman Leshchinskiy 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 = {-# INLINE bar #-}
>> bar =
>>
>> We did ask to inline bar, after all.
On 15 February 2011 15:12, Roman Leshchinskiy 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 =
> {-# INLINE bar #-}
> bar =
>
> We did ask to inline bar, after all.
Well, yes, but when considerin
Max Bolingbroke wrote:
> On 15 February 2011 11:23, Roman Leshchinskiy 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 :
>>
>> foo = bar
>> {-# INLINE bar #-}
>> bar =
>>
>> It mig
On 15 February 2011 11:23, Roman Leshchinskiy 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 :
>
> foo = bar
> {-# INLINE bar #-}
> bar =
>
> It might work with the current implementati
Max Bolingbroke wrote:
> 2011/2/15 Simon Peyton-Jones :
>
>> 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
2011/2/15 Simon Peyton-Jones :
> 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 motivation. Of course, a
Hello,
2011/2/15 Simon Peyton-Jones
>
> 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 this in the user's
---
| From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
| boun...@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
2011/2/15 Gábor Lehel :
> 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 separately for e
On Tue, Feb 15, 2011 at 12:48 AM, Max Bolingbroke
wrote:
> On 14 February 2011 21:43, Patrick Bahr 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
On 14 February 2011 21:43, Patrick Bahr 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 can't write i
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
> toIn
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:
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 Vissch
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
| "transform
| 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) = tran
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 poi
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 th
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 Ju
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
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:
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 (b
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
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, gi
30 matches
Mail list logo
