Den 2017-12-02 kl. 21:56, skrev Joachim Breitner:
With a wee bit of higher-order matching, one might make `u` and `v`
functions and instead write:
foo (\ x -> fmap (u x) (v x)) = bar u v
In that case I'd expect `u` and `v` to be synthesized rather than
literally matched. For instance, `foo (\
Hi,
Am Samstag, den 02.12.2017, 12:59 -0800 schrieb Conal Elliott:
> Thanks for the reply, Ed.
>
> > I'd assume that `x` didn't occur in either `u` or `v`
>
> This is exactly the issue I'm wondering about. Since rewrite rules
> admit lambdas and only first-o
Thanks for the reply, Ed.
> I'd assume that `x` didn't occur in either `u` or `v`
This is exactly the issue I'm wondering about. Since rewrite rules admit
lambdas and only first-order matching, I'm wondering whether they're
interpreted as you did (and I'd tend t
like forall u v. exists x. ...
Under that view, the warnings are accurate, and the rewrite is pretty
purely syntactic.
I don't see how we could write using our current vocabulary that which you
want.
On Sun, Dec 3, 2017 at 4:50 AM, Conal Elliott wrote:
> Is there a written explanation and/or ex
Is there a written explanation and/or examples of rewrite rules involving a
LHS lambda? Since rule matching is first-order, I'm wondering how terms
with lambda are matched on the LHS and substituted into on the RHS. For
instance, I want to restructure a lambda term as follows:
> foo (\ x
it is public code.
Ok, I'm heading in this direction and then I figure out that the parser
for the rewrite rules doesn't even reject obvious syntax errors.
Say I have a data types:
data Word128 = Word128 Word64 Word64
and inspired by the `fromIntegral` rules for Word64 I wr
ket/9180.
>
> You can also ask for review if it is public code.
Ok, I'm heading in this direction and then I figure out that the parser
for the rewrite rules doesn't even reject obvious syntax errors.
Say I have a data types:
data Word128 = Word128 Word64 Word64
and inspir
> If I write a library that includes rewrite rules, how can I ensure
> that they fire in client code that someone else writes? What
> guarantees (however loose) are there?
very little. The best one can do right now is to know enough about Core
and the inliner to predict when things are goin
Michael Snoyman wrote:
> Could be I'm misunderstanding, but are you looking for -ddump-rule-firings?
Wasn't aware of that, but my question was a little more general.
If I write a library that includes rewrite rules, how can I ensure
that they fire in client code that someone else
Could be I'm misunderstanding, but are you looking for -ddump-rule-firings?
On Thu, Jan 12, 2017 at 10:46 AM, Erik de Castro Lopo
wrote:
> HI all,
>
> I'm having an look at rewrite rules, but something bugs me a little.
> How do I tell if my rewrite rules are fi
HI all,
I'm having an look at rewrite rules, but something bugs me a little.
How do I tell if my rewrite rules are firing or not? Even If I
introduce deliberate errors in the function name that is being
re-written I still don't get so much as a warning.
Cl
Welcome back, Simon!
Simon Peyton Jones writes:
> | Indeed, we could eliminate several hundred lines of boilerplate in GHC if
> we
> | could lift this restriction.
>
> Can you be more specific? Which hundreds of lines?
>
In particular the bindings in Data.Int and Data.Word (e.g. GHC.Int.eqIn
[mailto:b...@smart-cactus.org]
| Sent: 29 December 2016 14:50
| To: Conal Elliott ; George Colpitts
|
| Cc: glasgow-haskell-users@haskell.org; Simon Peyton Jones
|
| Subject: Re: GHC rewrite rules for class operations & laws
|
| On December 28, 2016 7:27:20 PM EST, Conal Elliott w
anchor until the issues and path forward are clearer. From my
> perspective, class methods are among the most natural and useful candidates
> for rewrite rules, since they tend to have associated laws, many (but not
> all) of which are helpful in optimization. The alternative I know (and
On December 28, 2016 7:27:20 PM EST, Conal Elliott wrote:
>Hi, George. Yes, please do add a task, hopefully to serve as a
>conversation
>anchor until the issues and path forward are clearer. From my
>perspective,
>class methods are among the most natural and useful candidates for
Hi, George. Yes, please do add a task, hopefully to serve as a conversation
anchor until the issues and path forward are clearer. From my perspective,
class methods are among the most natural and useful candidates for rewrite
rules, since they tend to have associated laws, many (but not all) of
Do you want me to add a task ticket to remove this restriction that rewrite
rules can't be used for class methods?
On Tue, Nov 22, 2016 at 8:06 AM Simon Peyton Jones via
Glasgow-haskell-users wrote:
> Conal
>
>
>
> Is it possible to apply GHC rewrite rules to class
Thanks, Simon. For now, I've added a module with aliases for all of my
class methods and law-based rewrite rules in terms of those aliases.
- Conal
On Tue, Nov 22, 2016 at 4:06 AM, Simon Peyton Jones
wrote:
> Conal
>
>
>
> Is it possible to apply GHC rewrite rules to class
Conal
Is it possible to apply GHC rewrite rules to class methods?
Not currently. See https://ghc.haskell.org/trac/ghc/ticket/11688, esp
comment:7 which gives links to similar examples.
https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13 gives more background.
It’d be great if someone
behave differently when optimized.
On Nov 17, 2016 11:40 AM, "Conal Elliott" wrote:
> Is it possible to apply GHC rewrite rules to class methods? From what I’ve
> read and seen, class methods get eliminated early by
> automatically-generated rules. Is there really no w
Is it possible to apply GHC rewrite rules to class methods? From what I’ve
read and seen, class methods get eliminated early by
automatically-generated rules. Is there really no way to postpone such
inlining until a later simplifier stage? The GHC Users Guide docs say no
<ht
mailto:ghc-d...@haskell.org>
Subject: GHC rewrite rules and constructor wrappers?
I'm trying to sort out the relationship of GHC rewrite rules and constructor
wrappers. I have rules like
> "reify/(:<)" reifyEP (:<) = kPrim VecSP
This rule seems to fire for `reifyEP ($W:<)` ra
I'm trying to sort out the relationship of GHC rewrite rules and
constructor wrappers. I have rules like
> "reify/(:<)" reifyEP (:<) = kPrim VecSP
This rule seems to fire for `reifyEP ($W:<)` rather than `reifyEP (:<)`. If
I'm tracking (uncertain), `($W:<)`
but if we unfold a loop combinator at compile time, GHC's
normal optimizations can take over from there):
http://www.haskell.org/pipermail/haskell-cafe/2009-February/056241.html
Just a note - there is a solution that doesn't require Template
Haskell which I use in my own code. Here is a sketch:
| II is where I'd like to be able to distinguish variables, constants,
| and complex expressions in the left-hand sides of RULES, and
| I and III are where I'd like control over the rewrite strategy, as
| in strategy combinators.
I'm deep in icfp submissions, so no time to reply properly.
Okay
2009/2/24 Claus Reinke :
> In the recently burried haskell-cafe thread "speed: ghc vs gcc",
> Bulat pointed out some of the optimizations that GHC doesn't
> do, such as loop unrolling. I suggested a way of experimenting with loop
> unrolling, using template haskell to bypass GHC's blindspot (it usu
| II is where I'd like to be able to distinguish variables, constants,
| and complex expressions in the left-hand sides of RULES, and
| I and III are where I'd like control over the rewrite strategy, as
| in strategy combinators.
I'm deep in icfp submissions, so no time to reply properly.
You can
_s193'
is the counter variable, 'ww2_s197' is the accumulator):
$wloopW_s19k
(GHC.Prim.+# ww1_s193 8)
(GHC.Prim.+# (GHC.Prim.*# 8 ww1_s193) (GHC.Prim.+# 28 ww2_s197))
Nice. But I'd like to get there without cheating, with generally
applicable RULES. How?
erstand correctly, -fvia-C is on its way out - is
that correct, and what plans are there for recovering the optimizations
previously left to GCC?
The next thing I was looking at was rewrite rules, the obvious GHC
tool for implementing this kind of rule
(var+const1)+(var+const2) ==> 2*var + con
| This is the main wibble people forget when writing rules -- inlining.
| In your example, 'gen' is so cheap, it is immediately
| inlined, so it won't be available to match on in your rule.
I'll add a note in the user manual about this.
In general, GHC tries RULES before inlining. In this parti
thanks,
it works fine now.
2008/5/27 Don Stewart <[EMAIL PROTECTED]>:
> jakubuv:
>> Thanks lot, it works now. Now, I have just a simple question:
>>
>> Is there any chance to make rewriting working in ghci ?
>
> I think you can actually enable them by putting:
>
> {-# OPTIONS -frewrite-rules #-}
jakubuv:
> Thanks lot, it works now. Now, I have just a simple question:
>
> Is there any chance to make rewriting working in ghci ?
I think you can actually enable them by putting:
{-# OPTIONS -frewrite-rules #-}
at the top of the file to be interpreted. Works for me, anyway.
-- Don
_
Thanks lot, it works now. Now, I have just a simple question:
Is there any chance to make rewriting working in ghci ?
jan.
2008/5/27 Don Stewart <[EMAIL PROTECTED]>:
> jakubuv:
>> Hi,
>>
>> I'm trying to find out how the GHC rewrite rules pragma work, but I
jakubuv:
> Hi,
>
> I'm trying to find out how the GHC rewrite rules pragma work, but I'm
> not able to make it working. I have this simple example, where I would
> like to specialize the function gen to spec on strings:
>
> {-# OPTIONS -O2 -fglasgow-exts #-}
&g
Hi,
I'm trying to find out how the GHC rewrite rules pragma work, but I'm
not able to make it working. I have this simple example, where I would
like to specialize the function gen to spec on strings:
{-# OPTIONS -O2 -fglasgow-exts #-}
gen :: [a] -> a
gen = head
{-# RULES "
On 3/30/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
Would someone care to document this at
http://haskell.org/haskellwiki/GHC/Using_rules
Thanks! I added a section at
http://haskell.org/haskellwiki/GHC/Using_rules#Rules_and_method_sharing
.
Eric
_
.org
| Subject: Arrows and GHC rewrite rules
|
| In GHC's Control.Arrow implementation, there are several rewrite rules
| which exploit some properties of arrows. For example,
|
| > "compose/arr" forall f g . arr f >>> arr g = arr (f >>> g)
| > "first/a
In GHC's Control.Arrow implementation, there are several rewrite rules
which exploit some properties of arrows. For example,
"compose/arr" forall f g . arr f >>> arr g = arr (f >>> g)
"first/arr" forall f . first (arr f) = arr (first f)
"second
(moved to glasgow-haskell-users, hoping it's more appropriate)
Chris wrote:
Hi All. I am a student and a noob to Haskell. I am having some
trouble with an example from the paper "Playing by the rules:
Rewriting as a practical optimisation technique in GHC" by Simon
Peyton Jones, Andrew Tol
39 matches
Mail list logo
