On Fri, 2007-03-30 at 17:06 +0100, Neil Mitchell wrote:
> The user has called a function which explicitly annotates which
> classes it requires. The user is completely allowed to write "instance
> Ord a where compare = undefined", and they should have a reasonable
> expectation that unless Ord a =
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.ht
Hi Gregory,
On Fri, Mar 30, 2007 at 06:17:10PM -0400, Gregory Wright wrote:
>
> On Mar 30, 2007, at 8:22 AM, Ian Lynagh wrote:
>
> >On Fri, Mar 30, 2007 at 09:31:07AM +0100, Simon Marlow wrote:
> >>Ian Lynagh wrote:
> >>>
> >>>OK, so we know that the wrong value is being passed to
> >>>newPinne
Hi Ian,
On Mar 30, 2007, at 8:22 AM, Ian Lynagh wrote:
On Fri, Mar 30, 2007 at 09:31:07AM +0100, Simon Marlow wrote:
Ian Lynagh wrote:
OK, so we know that the wrong value is being passed to
newPinnedByteArray#, right? There aren't many calls to that:
libraries/base/Foreign/Marshal/Alloc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Neil Mitchell wrote:
> Hi
>
> I was thinking about this, and I think pattern matching with rules and
> class context pretty much _guarantees_ a change in semantics. If you
> match on a class constraint, the pretty much only reason to do so is
> to exp
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 still have questions after reading it, you can always ask here
I'm curious when and how GHC applies rewrite rules,
and how expensive it is.
Felix also has rewrite rules. It uses a woefully expensive
algorithm to apply them:
1) elide rules that refer to functions that have
themselves been elided since they can't be applied.
2) For each rule in turn
For
Hi
I was thinking about this, and I think pattern matching with rules and
class context pretty much _guarantees_ a change in semantics. If you
match on a class constraint, the pretty much only reason to do so is
to exploit that type class. Unfortunately, this isn't safe.
The user has called a fu
Well observed. There are two difficulties here.
First is a persistent bug-bear: GHC compiles
foo :: SF (Int,Int) (Int,Int)
foo = first (arr (+1)) >>> first (arr (+2) >>> arr (+3))
thus:
dsf :: Arrow SF
dsf = ...
first_1 = Control.Arrow.first SF dsf
| In particular, it would be nice to be able to specialise based on the
| instances, as we do for [a] --> [Int], e.g.
|
| RULES sum = sumInt :: [Int] -> Int
|
| is fine in the current system. So I could imagine some nice
| specialisations based on say, the good old Ord:
|
| RULES nub = nubO
Several things to say on this thread.
First, Pepe's examples below only work because of a bug in GHC. Consider
RULE forall (x::a->Int). f x = g
You'd only expect this to match on arguments of the given type; but it
(wrongly) matches always. That's bad. I'm fixing it; and that will stop
11 matches
Mail list logo
