
Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker. Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a -- a type with phantom type arguments. data E ins outs = E -- a function that relates E and its inputs. projectInsType :: E ins outs -> ins projectInsType = error "projectInsType gets evaluated." -- "register" function. register :: a -> a -> a register def a = def -- a simple addition. add2 :: (ToWires a, Num a) => (a,a) -> a add2 (a,b) = a+b First I have a function: func :: (ToWires a, Num a) => Maybe a -> a func mbA = currentSum where x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum It typechecks and works just fine after some transformation. The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) => E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding "mbA = projectInsType r". Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2. If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine. Full source code is in attachment. I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3. Should I fill a bug report or maybe I misunderstood something?

Seems like let-generalization is at work here. Types of all values in the "where" section are inferred basically as if they are declared at the top level. Therefore, inheritance fails without NoMonomorphismRestriction. There is a proposal (from Big Simon) to remove let-generalization: http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let... On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker.
Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a
-- a type with phantom type arguments. data E ins outs = E
-- a function that relates E and its inputs. projectInsType :: E ins outs -> ins projectInsType = error "projectInsType gets evaluated."
-- "register" function. register :: a -> a -> a register def a = def
-- a simple addition. add2 :: (ToWires a, Num a) => (a,a) -> a add2 (a,b) = a+b
First I have a function: func :: (ToWires a, Num a) => Maybe a -> a func mbA = currentSum where x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
It typechecks and works just fine after some transformation.
The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) => E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding "mbA = projectInsType r".
Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2.
If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine.
Full source code is in attachment.
I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3.
Should I fill a bug report or maybe I misunderstood something?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Cool. It works.
Thank you very much!
2011/6/19 Miguel Mitrofanov
Seems like let-generalization is at work here.
Types of all values in the "where" section are inferred basically as if they are declared at the top level. Therefore, inheritance fails without NoMonomorphismRestriction.
There is a proposal (from Big Simon) to remove let-generalization: http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let...
On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker.
Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a
-- a type with phantom type arguments. data E ins outs = E
-- a function that relates E and its inputs. projectInsType :: E ins outs -> ins projectInsType = error "projectInsType gets evaluated."
-- "register" function. register :: a -> a -> a register def a = def
-- a simple addition. add2 :: (ToWires a, Num a) => (a,a) -> a add2 (a,b) = a+b
First I have a function: func :: (ToWires a, Num a) => Maybe a -> a func mbA = currentSum where x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
It typechecks and works just fine after some transformation.
The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) => E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding "mbA = projectInsType r".
Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2.
If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine.
Full source code is in attachment.
I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3.
Should I fill a bug report or maybe I misunderstood something?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Not just a proposal any more. :-) GHC 7.0 does not generalize local let bindings in some situations. See here for information: http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
There is a proposal (from Big Simon) to remove let-generalization: http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let...
On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker.
Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a
-- a type with phantom type arguments. data E ins outs = E
-- a function that relates E and its inputs. projectInsType :: E ins outs -> ins projectInsType = error "projectInsType gets evaluated."
-- "register" function. register :: a -> a -> a register def a = def
-- a simple addition. add2 :: (ToWires a, Num a) => (a,a) -> a add2 (a,b) = a+b
First I have a function: func :: (ToWires a, Num a) => Maybe a -> a func mbA = currentSum where x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
It typechecks and works just fine after some transformation.
The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) => E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding "mbA = projectInsType r".
Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2.
If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine.
Full source code is in attachment.
I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3.
Should I fill a bug report or maybe I misunderstood something?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Yeah, seems to work too.
Отправлено с iPhone
Jun 20, 2011, в 10:55, "Corey O'Connor"
Not just a proposal any more. :-) GHC 7.0 does not generalize local let bindings in some situations. See here for information: http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
There is a proposal (from Big Simon) to remove let-generalization: http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let...
On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker.
Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a
-- a type with phantom type arguments. data E ins outs = E
-- a function that relates E and its inputs. projectInsType :: E ins outs -> ins projectInsType = error "projectInsType gets evaluated."
-- "register" function. register :: a -> a -> a register def a = def
-- a simple addition. add2 :: (ToWires a, Num a) => (a,a) -> a add2 (a,b) = a+b
First I have a function: func :: (ToWires a, Num a) => Maybe a -> a func mbA = currentSum where x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
It typechecks and works just fine after some transformation.
The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) => E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding "mbA = projectInsType r".
Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2.
If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine.
Full source code is in attachment.
I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3.
Should I fill a bug report or maybe I misunderstood something?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

The fact is that (Num a) context works and (ToWires a, Num a) context
doesn't. At least in 6.12.1.
This still looks to me like a bug.
2011/6/19 Miguel Mitrofanov
Seems like let-generalization is at work here.
Types of all values in the "where" section are inferred basically as if they are declared at the top level. Therefore, inheritance fails without NoMonomorphismRestriction.
There is a proposal (from Big Simon) to remove let-generalization: http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let...
On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker.
Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a
-- a type with phantom type arguments. data E ins outs = E
-- a function that relates E and its inputs. projectInsType :: E ins outs -> ins projectInsType = error "projectInsType gets evaluated."
-- "register" function. register :: a -> a -> a register def a = def
-- a simple addition. add2 :: (ToWires a, Num a) => (a,a) -> a add2 (a,b) = a+b
First I have a function: func :: (ToWires a, Num a) => Maybe a -> a func mbA = currentSum where x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
It typechecks and works just fine after some transformation.
The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) => E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding "mbA = projectInsType r".
Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2.
If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine.
Full source code is in attachment.
I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3.
Should I fill a bug report or maybe I misunderstood something?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

GHC 6.12 introduces MonoLocalBinds, which disables polymorphic values
in let statements.
Your original code works for me if I use -XNoMonoLocalBinds
-XNoMonomorphismRestriction.
On Mon, Jun 20, 2011 at 9:02 AM, Serguey Zefirov
The fact is that (Num a) context works and (ToWires a, Num a) context doesn't. At least in 6.12.1.
This still looks to me like a bug.
2011/6/19 Miguel Mitrofanov
: Seems like let-generalization is at work here.
Types of all values in the "where" section are inferred basically as if they are declared at the top level. Therefore, inheritance fails without NoMonomorphismRestriction.
There is a proposal (from Big Simon) to remove let-generalization: http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let...
On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker.
Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a
-- a type with phantom type arguments. data E ins outs = E
-- a function that relates E and its inputs. projectInsType :: E ins outs -> ins projectInsType = error "projectInsType gets evaluated."
-- "register" function. register :: a -> a -> a register def a = def
-- a simple addition. add2 :: (ToWires a, Num a) => (a,a) -> a add2 (a,b) = a+b
First I have a function: func :: (ToWires a, Num a) => Maybe a -> a func mbA = currentSum where x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
It typechecks and works just fine after some transformation.
The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) => E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding "mbA = projectInsType r".
Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2.
If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine.
Full source code is in attachment.
I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3.
Should I fill a bug report or maybe I misunderstood something?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Dave Menendez

Thank you very much. I'll try that too.
2011/6/20 David Menendez
GHC 6.12 introduces MonoLocalBinds, which disables polymorphic values in let statements.
Your original code works for me if I use -XNoMonoLocalBinds -XNoMonomorphismRestriction.
On Mon, Jun 20, 2011 at 9:02 AM, Serguey Zefirov
wrote: The fact is that (Num a) context works and (ToWires a, Num a) context doesn't. At least in 6.12.1.
This still looks to me like a bug.
2011/6/19 Miguel Mitrofanov
: Seems like let-generalization is at work here.
Types of all values in the "where" section are inferred basically as if they are declared at the top level. Therefore, inheritance fails without NoMonomorphismRestriction.
There is a proposal (from Big Simon) to remove let-generalization: http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let...
On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker.
Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a
-- a type with phantom type arguments. data E ins outs = E
-- a function that relates E and its inputs. projectInsType :: E ins outs -> ins projectInsType = error "projectInsType gets evaluated."
-- "register" function. register :: a -> a -> a register def a = def
-- a simple addition. add2 :: (ToWires a, Num a) => (a,a) -> a add2 (a,b) = a+b
First I have a function: func :: (ToWires a, Num a) => Maybe a -> a func mbA = currentSum where x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
It typechecks and works just fine after some transformation.
The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) => E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding "mbA = projectInsType r".
Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2.
If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine.
Full source code is in attachment.
I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3.
Should I fill a bug report or maybe I misunderstood something?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Dave Menendez
http://www.eyrie.org/~zednenem/

Defaulting. Inferred type of "r" is still polymorphic – r :: E ins outs – but type of "x", "nextSum" and "currentSum" is defaulted to "Integer". Try adding "default ()" to your program, and you'll see the same error again. Or, if you enable NoMonomorphismRestriction (or MonoLocalBinds – I didn't know it works in 6.12 also), you'll see that the type of "nextSum" etc. is derived as "Num a => a". On 20 Jun 2011, at 17:02, Serguey Zefirov wrote:
The fact is that (Num a) context works and (ToWires a, Num a) context doesn't. At least in 6.12.1.
This still looks to me like a bug.
2011/6/19 Miguel Mitrofanov
: Seems like let-generalization is at work here.
Types of all values in the "where" section are inferred basically as if they are declared at the top level. Therefore, inheritance fails without NoMonomorphismRestriction.
There is a proposal (from Big Simon) to remove let-generalization: http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let...
On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker.
Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a
-- a type with phantom type arguments. data E ins outs = E
-- a function that relates E and its inputs. projectInsType :: E ins outs -> ins projectInsType = error "projectInsType gets evaluated."
-- "register" function. register :: a -> a -> a register def a = def
-- a simple addition. add2 :: (ToWires a, Num a) => (a,a) -> a add2 (a,b) = a+b
First I have a function: func :: (ToWires a, Num a) => Maybe a -> a func mbA = currentSum where x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
It typechecks and works just fine after some transformation.
The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) => E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a -> a Nothing -> 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum
Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding "mbA = projectInsType r".
Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2.
If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine.
Full source code is in attachment.
I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3.
Should I fill a bug report or maybe I misunderstood something?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (5)
-
Corey O'Connor
-
David Menendez
-
MigMit
-
Miguel Mitrofanov
-
Serguey Zefirov