Am Freitag, den 15.08.2014, 23:10 +0300 schrieb Wolfgang Jeltsch:
Hi,
the module Control.Arrow declares a set of rules for the Arrow class. It
is marked “Trustworthy”, probably to allow these rules to actually fire.
Now these rules are only correct for class instances that actually
That's an interesting question. I'm not even close to an expert, but I
*think* that parametricity prevents those particular rules from breaking
Safe Haskell guarantees. The laws may not *hold* for a broken instance, but
I don't *think* that lets you break type safety or IO encapsulation.
On Nov
| So I wonder: Why is rule map id2 not enough here?
Compile with -ddump-rules. What you see is below.
* The rule map id actually has an LHS like this:
myMap a (id a)
where the (id a) is a type application. It'll ONLY match a term that looks
like
myMap ty (id ty)
where ty is
Hi Kazu,
On Tue, Aug 28, 2012 at 01:37:32PM +0900, Kazu Yamamoto wrote:
I seems to us (my friends and me) that term rewriting rules for
ByteString are not fired in recent GHCs.
Thanks for the report. I've filed a ticket here:
http://hackage.haskell.org/trac/ghc/ticket/7374
Thanks
Ian
Another data point:
The bytestring 'break' rule fired fine for me (GHC 7.4.1 Linux x86-64).
On Mon, Aug 27, 2012 at 9:37 PM, Kazu Yamamoto k...@iij.ad.jp wrote:
Hello,
I seems to us (my friends and me) that term rewriting rules for
ByteString are not fired in recent GHCs.
6.12.3
On Fri, 2007-03-30 at 13:04 -0700, Tim Chevalier wrote:
On 3/30/07, skaller [EMAIL PROTECTED] wrote:
I'm curious when and how GHC applies rewrite rules,
and how expensive it is.
Have you seen the Playing By Rules paper?
http://research.microsoft.com/~simonpj/Papers/rules.htm
If you
haskell:
Is there any way to use RULES substitutions with type classes?
I'm writing a reactive programming arrow (same idea as Yampa, different
design goals), and it would help performance (and not just in the speed
sense) to be able to tell when a value derived with arr hasn't changed.
So
On 29/03/2007, at 11:38, Mike Hamburg wrote:
Is there any way to use RULES substitutions with type classes?
I'm writing a reactive programming arrow (same idea as Yampa,
different
design goals), and it would help performance (and not just in the
speed
sense) to be able to tell when a
when performing strictness/abscence/one-shot analysis, are rule bodies
taken into account?
No.
like, would the following cause trouble making const
no longer absent in its second argument?
const x y = x
{-# RULE const/seq forall a b . const a b = seq b a #-}
by trouble I mean the compiler
]
| On Behalf Of Donald Bruce Stewart
| Sent: 12 July 2006 01:41
| To: Malcolm Wallace
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: RULES pragmas
|
| Malcolm.Wallace:
| I have a question about {-# RULES #-} pragmas. Here is a very
simple
| attempt to use them:
|
| module Simplest
[EMAIL PROTECTED] (Donald Bruce Stewart) wrote:
So what am I doing wrong? And is there any way to ask the compiler
to give a warning if the RULES pragma contains errors?
In this case, it's because it's missing -fglasgow-exts, I think.
Ah, thank you. The missing (and undocumented)
Malcolm Wallace [EMAIL PROTECTED] wrote:
Ah, thank you. The missing (and undocumented) option.
Actually, now I came to submit a patch to the manual, I discover that it
/is/ documented, but at the beginning of section 7. (But on the index
page on the web, the link to section 7 is two whole
Malcolm Wallace wrote:
Malcolm Wallace [EMAIL PROTECTED] wrote:
Ah, thank you. The missing (and undocumented) option.
Actually, now I came to submit a patch to the manual, I discover that it
/is/ documented, but at the beginning of section 7. (But on the index
page on the web, the link
Malcolm.Wallace:
I have a question about {-# RULES #-} pragmas. Here is a very simple
attempt to use them:
module Simplest where
{-# RULES
simplestRule forall x. id (id x) = x
#-}
myDefn = id (id 42)
I want to verify whether ghc-6.4.1 does actually fire
I'm afraid that RULES are applied *after* type checking and dictionary
construction. Recall that freeze has type
freeze :: (Ix i, MArray a e m, IArray b e) = a i e - m (b i e)
Your original RULE gives
Could not deduce (Unboxed e, HasDefaultValue e)
from the context (IArray UArray
Definitely not at present, and I see no easy way to implement it.
RULES are implemented by simple matching in Core. A call to nub will have an
Eq dictionary, but Core knows nothing of instance declarations, and has no clue
how to make an Ord dictionary. But an Ord dictionary is what you want
Hello John,
Monday, March 20, 2006, 2:49:14 PM, you wrote:
JM Is it possible to create a RULES that fires only if a type has a given
JM class constraint? something like:
snub :: Ord a = [a] - [a]
snub xs = f Set.empty xs where
f _ [] = []
f (x:xs) set
| x `Set.member` set =
On Mon, Mar 20, 2006 at 12:09:41PM -, Simon Peyton-Jones wrote:
Definitely not at present, and I see no easy way to implement it.
RULES are implemented by simple matching in Core. A call to nub will
have an Eq dictionary, but Core knows nothing of instance
declarations, and has no clue
On 03 November 2005 17:08, Jan-Willem Maessen wrote:
I've recently been experimenting with unsafeFreeze/unsafeThaw in
GHC. Judicious use of these functions vastly reduces GC overhead in
Data.HashTable. However, a slightly mis-timed GC will cause the
whole mess to crash. I am attempting to
|
| I suppose I'm being bitten by User's Guide 7.8.2:
|
| If more than one rule matches a call, GHC will choose one
arbitrarily
| to apply.
|
| even if a bit later it says:
|
| So a rule only matches if the types match too.
|
| Am I understanding right and it's that so?
I think so.
Rules.hs:
module Rules where
my_id :: a - a
my_id a = a
my_int_id :: Int - Int
my_int_id a = a
{-# RULES my_id = my_int_id #-}
Each rule should begin with a string, like:
{-# RULES my_id my_id = my_int_id #-}
{-# SPECIALIZE my_id :: Int - Int = my_int_id #-}
These kind of
| PrelBase contains the appended code. Am I correct in
| assuming that the stuff is structured as it is, because the
| "map" rule first `breaks' the map `open', which exposes it
| to the various foldr/build rules, and if no foldr/build rule
| matches, the "mapList" rule `closes' it again in a
Simon Peyton-Jones [EMAIL PROTECTED] wrote,
Is this a propos of your new transformations for parallelism?
Precisely! Trying to figure out how to generate the fastest
possible array code with GHC.
Manuel
___
Glasgow-haskell-users mailing list
You need to write the function in prefix form, thus:
{-# RULES "T" forall x. (||) True x = True #-}
I know this is stupid, but I havn't got around to fixing it.
Simon
-Original Message-
From: [EMAIL PROTECTED]
Sent: Thursday, July 08, 1999 2:46 PM
To: [EMAIL PROTECTED]
On 07-Jun-1999, S.D.Mechveliani [EMAIL PROTECTED] wrote:
One more question on the program simplification and `bottom'.
People say, that the transformations like x - x - 0 :: Integer
are hardly ever applicable, because x may occur `undefined'.
This issue was already resolved --
On Mon, 7 Jun 1999, S.D.Mechveliani wrote:
One more question on the program simplification and `bottom'.
People say, that the transformations like x - x - 0 :: Integer
are hardly ever applicable, because x may occur `undefined'.
There is another problem lurking here as well.
There is another problem lurking here as well. Namely space issues.
Consider the following program. It runs in constant space.
let xs = 1..n
x = head xs
in x - x + last xs + x
Now transforming it using
M - M - 0 and
0 + M - M
yields
let xs = 1..n
x = head xs
in last xs
{rules Num a= x::a, y::[a] ==
x+y = [x]+y}
instance Num a = Num [a] where ...
one could expect for x :: Num b=b the casting
x + [x,y] --
[x] + [x,y]
Provided the two sides of the rules
Simon Peyton-Jones wrote:
Another question on *rules*.
Could they help the implicit type casting?
For example, with
{rules Num a= x::a, y::[a] == x+y = [x]+y}
instance Num a = Num [a] where ...
one could expect for x :: Num b=b
Another question on *rules*.
Could they help the implicit type casting?
For example, with
{rules Num a= x::a, y::[a] == x+y = [x]+y}
instance Num a = Num [a] where ...
one could expect for x :: Num b=b the casting
Thanks to everyone who has contributed to the discussion about
transformation rules. There is clearly something inteeresting
going on here!
There is clearly a huge spectrum of possibilities, ranging from
nothing at all to a full theorem-proving system. In adding rules
to GHC I'm trying to
I think that John Darlington's group at Imperial College were to first
to use rule driven program transformation in their various skelton/coordination
language parallelising compilers.
Here, Tore Bratvold used simple higher order function/composition
distribution transformation rules in his
Lennart Augustsson writes:
Wolfram Kahl wrote:
In the end, my dreams even include a proof format
that can be checked by the compiler :-)
Dependent types! That's all you need.
Absolutely!
I have read your Cayenne paper
( http://www.cs.chalmers.se/%7Eaugustss/cayenne/paper.ps )
Wolfram Kahl wrote:
In the end, my dreams even include a proof format
that can be checked by the compiler :-)
Dependent types! That's all you need.
--
-- Lennart
At 11:02 + 1999/05/03, Wolfram Kahl wrote:
With respect to the new RULES mechanism presented by
Simon Peyton Jones (Thu, 22 Apr 1999),
Carsten Schultz [EMAIL PROTECTED] writes
[...]
And what about algebraic simplification? Say,
The same applies to our beloved monads.
The compiler
Hans aberg writes:
For expressing algebraic relations, I think one can use universal algebra
by factoring through the free universal algebra of a particular set of
relations. For example, if one wants to state that a binary operator is
commutative, one can say that is should be defined
Mark P Jones [EMAIL PROTECTED] writes:
...
[Aside: As a general comment to all readers of the Haskell mailing
list, perhaps I can suggest: if you've posted something to the list
within the last two weeks, and it hasn't received the kind of
response that you were expecting, then please
At 10:08 -0700 1999/05/04, peter [EMAIL PROTECTED] wrote:
Hans aberg writes:
When a group is expressed as a class G having operations e, *, and -1,
then implicitly (via well defined semantics), a group is a quadruple,
so I don't think the quadruple need be explicit in the Haskell program.
The
Wolfram Kahl writes:
One might even imagine extended instance declarations
like the following:
instance Monad []
{-# PROOF
"Monad-rightId"
forall f.f = return
= concat (map return f)
= concat (map (:[]) f)
= case f of
I've seen a couple of messages now about Simon's proposal for
a RULES mechanism in Haskell, but it's clear that I've missed
several of the messages, including the original proposal. I
suspect this is a result of recent changes in the way that the
list is handled, which should be resolved by now.
40 matches
Mail list logo
