Re: [GHC] #6134: Incorrect ambiguity error with functional dependencies
#6134: Incorrect ambiguity error with functional dependencies -+-- Reporter: diatchki| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) |Version: 7.4.1 Resolution: fixed | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: typecheck/should_compile/T6134 | Blockedby: Blocking: |Related: -+-- Changes (by simonpj): * status: new = closed * testcase: = typecheck/should_compile/T6134 * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6134#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #6134: Incorrect ambiguity error with functional dependencies
#6134: Incorrect ambiguity error with functional dependencies
+---
Reporter: diatchki | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type checker) | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: GHC rejects valid
program
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
+---
Changes (by simonpj):
* difficulty: = Unknown
Comment:
Right. This check, on user type signatures, is ''purely'' there to report
types that cannot possibly be used. So for example we want to reject:
{{{
f :: C [a] = Int
}}}
The idea is there can be no legal calls to `f` because every call will
give rise to an ambiguous constraint. We could soundly omit the ambiguity
check on type signatures entirely, at the expense of delaying ambiguity
errors to call sites.
But is every call to `f` ambiguous? After all, we might have
{{{
intance C [a] where ...
}}}
at the call site. So maybe that type is ok! What about the
quintessentially ambiguous type
{{{
f :: C a = Int
}}}
Well, with `UndecidableInstances` we could have
{{{
instance C a where ...
}}}
and now a call could be legal after all! (But only with
`UndecidableInstances`.
So it's clear that the present check is too conservative (rejects
perfectly ok programs). Using the visible fundeps is also too
conservative. Consider
{{{
class C a b where ...
class D a b | a - b where ...
instance D a b = C [a] b where...
f :: C a b = a - a
}}}
Here `f`'s type looks ambiguous in `b`, but here's a legal call:
{{{
...(f [True])...
}}}
That gives rise to a `(C [Bool] beta)` constraint, and using the instance
means we need `(D Bool beta)` and that fixes `beta` via `D`'s fundep!
So I think the only types we can reject as definitely ambiguous are ones
like this
{{{
f :: (Cambig, Cnonambig) = tau
}}}
where
* `Cambig`, `Cnonambig` are each a set of constraints.
* `fv(Cambig)` does not intersect `fv( Cnonambig = tau )`
* The constraints in `Cambig` are all of form `(C a b c)` where a,b,c are
type variables
* `Cambig` is non-empty
* `-XUndecidableInstances` is not on.
That narrows the scope of the test considerably. Make sense?
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6134#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #6134: Incorrect ambiguity error with functional dependencies
#6134: Incorrect ambiguity error with functional dependencies
---+
Reporter: diatchki | Owner:
Type: bug| Status: new
Priority: normal | Component: Compiler (Type
checker)
Version: 7.4.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: GHC rejects valid program | Testcase:
Blockedby: | Blocking:
Related: |
---+
GHC reject a program as ambiguous when it is not. Consider the following
example:
{{{
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
FlexibleContexts #-}
class C a b | a - b where
f :: a - b
test :: (Show a, C Int a) = Bool
test = show (f (1 :: Int)) == 1
}}}
GHC rejects the program with the following error:
{{{
Ambiguous constraint `C Int a'
At least one of the forall'd type variables mentioned by the
constraint
must be reachable from the type after the '='
In the type signature for `test': test :: (Show a, C Int a) = Bool
}}}
The only variable, {{{a}}}, is fully determined by the type `Int` via the
functional dependency on class `C` so there is no ambiguity.
These sort of errors crop up when we desugar implicit parameters into uses
of the `IP` class (which has a functional dependency).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6134
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5860: Ambiguity between redundant imports
#5860: Ambiguity between redundant imports
---+
Reporter: elliottt | Owner:
Type: feature request | Status: closed
Priority: normal| Milestone:
Component: Compiler |Version: 7.4.1
Resolution: fixed | Keywords: module system
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by simonpj):
* status: new = closed
* resolution: = fixed
Comment:
A patch is irresistable. I buy:
{{{
commit 68b59cb6fadecb7712e414c4bdb60e4e676e
Author: Trevor Elliott tre...@galois.com
Date: Thu Feb 9 11:53:34 2012 -0800
Distinguish between normal and qualified unused imports
---
compiler/rename/RnNames.lhs |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/compiler/rename/RnNames.lhs b/compiler/rename/RnNames.lhs
index b3a3f83..b1a61db 100644
--- a/compiler/rename/RnNames.lhs
+++ b/compiler/rename/RnNames.lhs
@@ -1512,7 +1512,10 @@ warnUnusedImport (L loc decl, used, unused)
+ ptext (sLit import) + pp_mod
parens empty ]
msg2 = sep [pp_herald + quotes (pprWithCommas ppr unused),
text from module + quotes pp_mod + pp_not_used]
-pp_herald = text The import of
+pp_herald = text The + pp_qual + text import of
+pp_qual
+ | ideclQualified decl = text qualified
+ | otherwise = empty
pp_mod = ppr (unLoc (ideclName decl))
pp_not_used = text is redundant
}}}
Thanks. Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5860#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5860: Ambiguity between redundant imports
#5860: Ambiguity between redundant imports ---+ Reporter: elliottt | Owner: Type: feature request | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 7.4.1 Resolution: invalid | Keywords: module system Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = invalid Comment: Looks ok to me. The error message points to line 4, and the import of `Data.ByteString` on that line is indeed redundant. I suppose we could say The qualified import of ..., but I'm inclined to let this lie. Reopen if you disagree. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5860#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5860: Ambiguity between redundant imports
#5860: Ambiguity between redundant imports ---+ Reporter: elliottt | Owner: Type: feature request | Status: new Priority: normal| Milestone: Component: Compiler |Version: 7.4.1 Resolution:| Keywords: module system Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by elliottt): * status: closed = new * resolution: invalid = Comment: I can live with things the way they are, but I've attached a patch just in case that changes your mind :) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5860#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #5860: Ambiguity between redundant imports
#5860: Ambiguity between redundant imports
--+-
Reporter: elliottt | Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
Version: 7.4.1 | Keywords: module system
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
GHC reports this program:
{{{
module Test where
import Data.ByteString (ByteString)
import qualified Data.ByteString as S
test :: ByteString - ByteString
test x = x
}}}
as having a redundant import of Data.!ByteString:
{{{
$ ghc -c -Wall Test.hs
Test.hs:4:1:
Warning: The import of `Data.ByteString' is redundant
except perhaps to import instances from `Data.ByteString'
To import instances alone, use: import Data.ByteString()
}}}
However, removing the restricted import of Data.!ByteString will cause the
program to fail to compile, as the type is no longer available. The real
problem is with the qualified import of Data.!ByteString as S that is
never referenced in the program.
Would it be possible to change the message to distinguish between the
qualified import an the restricted import, by more than the line number?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5860
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1614: Type checker does not use fundep to avoid ambiguity
#1614: Type checker does not use fundep to avoid ambiguity -+-- Reporter: guest| Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler (Type checker) |Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -+-- Changes (by simonmar): * os: MacOS X = Multiple * architecture: x86 = Multiple -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1614#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1614: Type checker does not use fundep to avoid ambiguity
#1614: Type checker does not use fundep to avoid ambiguity -+-- Reporter: guest| Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler (Type checker) |Version: 6.7 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -+-- Changes (by simonpj): * status: new = closed * resolution: = wontfix Comment: I think we won't fix this; use type functions and equalities instead. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1614#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1614: Type checker does not use fundep to avoid ambiguity
#1614: Type checker does not use fundep to avoid ambiguity
+---
Reporter: guest|Owner:
Type: bug | Status: new
Priority: normal |Milestone: 6.8
Component: Compiler (Type checker) | Version: 6.7
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: MacOS X | Testcase:
Architecture: x86 |
+---
Comment (by chak):
This works with the latest head:
{{{
{-# OPTIONS_GHC -fglasgow-exts #-}
module E where
data E v a = E a
data RValue
instance (v ~ RValue, Eq a) = Eq (E v a) where
E x == E y = x == y
a :: E v Int
a = undefined
foo = a == a
}}}
So, I agree with SimonPJ, death to functional dependencies. This solution
was btw SimonPJ's idea (he just couldn't test it as his latest build
wasn't complete yet.)
`t1 ~ t2` is an equality constraint and part of the type families patch
that landed in the head yesterday.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1614
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1614: Type checker does not use fundep to avoid ambiguity
#1614: Type checker does not use fundep to avoid ambiguity +--- Reporter: guest|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: x86 | +--- Comment (by guest): Using v ~ RValue works like a charm! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1614 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1614: Type checker does not use fundep to avoid ambiguity
#1614: Type checker does not use fundep to avoid ambiguity
+---
Reporter: guest|Owner:
Type: bug | Status: new
Priority: normal |Milestone: 6.8
Component: Compiler (Type checker) | Version: 6.7
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: MacOS X | Testcase:
Architecture: x86 |
+---
Comment (by guest):
What I'm really trying to use this for is to solve a different problem,
which might have a more direct solution. I have an instance 'Eq (E RValue
a)' and I want the type checker to pick that one when it runs into the
constraint 'Eq (E v a)', because there's never going to be any other
instance of 'Eq (E ...)'.
Of course, the type checker needs to be convinced of this. So I tried
'IsRValue v = Eq (E v a)', where IsRValue has a fundep that forces it to
have (at most) one instance.
But then I ran into the bug I reported.
I think using this idiom is a reasonable way to tell the type checker that
there will be at most one instance of a particular class.
The code:
{{{
{-# OPTIONS_GHC -fglasgow-exts #-}
module E where
data E v a = E a
data RValue
{-
-- This fails with the message below.
instance (Eq a) = Eq (E RValue a) where
E x == E y = x == y
--No instance for (Eq (E v Int))
-- arising from a use of `==' at E.hs:13:6-11
-}
-- This succeeds, but doesn't force v to be RValue
instance (Eq a) = Eq (E v a) where
E x == E y = x == y
{-
-- This fails with the message below.
instance (IsRValue v, Eq a) = Eq (E v a) where
E x == E y = x == y
class IsRValue a | - a
instance IsRValue RValue
--Ambiguous type variable `v' in the constraint:
-- `IsRValue v' arising from a use of `==' at E.hs:30:6-11
-}
a :: E v Int
a = undefined
foo = a == a
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1614
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1614: Type checker does not use fundep to avoid ambiguity
#1614: Type checker does not use fundep to avoid ambiguity
+---
Reporter: guest|Owner:
Type: bug | Status: new
Priority: normal |Milestone: 6.8
Component: Compiler (Type checker) | Version: 6.7
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: MacOS X | Testcase:
Architecture: x86 |
+---
Comment (by simonpj):
This is a variant of #1624. Why didn't you write this?
{{{
unC :: Int - Int
}}}
Do you have a real program in which this causes you a problem? Death to
functional dependencies, say I.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1614
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1614: Type checker does not use fundep to avoid ambiguity
I have a real program that causes this. I was just being nice and reducing
it to the smallest example I could come up with. :)
On 8/24/07, GHC [EMAIL PROTECTED] wrote:
#1614: Type checker does not use fundep to avoid ambiguity
+---
Reporter: guest|Owner:
Type: bug | Status: new
Priority: normal |Milestone: 6.8
Component: Compiler (Type checker) | Version: 6.7
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: MacOS X | Testcase:
Architecture: x86 |
+---
Comment (by simonpj):
This is a variant of #1624. Why didn't you write this?
{{{
unC :: Int - Int
}}}
Do you have a real program in which this causes you a problem? Death to
functional dependencies, say I.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1614
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1614: Type checker does not use fundep to avoid ambiguity
#1614: Type checker does not use fundep to avoid ambiguity +--- Reporter: guest|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: x86 | +--- Changes (by igloo): * milestone: = 6.8 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1614 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1614: Type checker does not use fundep to avoid ambiguity
#1614: Type checker does not use fundep to avoid ambiguity
--+-
Reporter: guest| Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type checker) |Version: 6.7
Severity: normal | Keywords:
Difficulty: Unknown | Os: MacOS X
Testcase: | Architecture: x86
--+-
Compiling the following module gives an error
{{{
module X where
class C a | - a
instance C Int
unC :: (C a) = a - Int
unC i = undefined
test :: Int
test = unC undefined
}}}
Error message:
{{{
X.hs:13:7:
Ambiguous type variable `a' in the constraint:
`C a' arising from a use of `unC' at X.hs:13:7-19
Probable fix: add a type signature that fixes these type variable(s)
}}}
But that is just plain wrong. The functional dependency in the definition
of C forces a to be Int. No other type is possible. So what's ambiguous
about that?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1614
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: import ambiguity
Hi, thanks for the report. Now fixed. --sigbjorn - Original Message - From: Dean Herington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, October 23, 2002 09:14 Subject: import ambiguity With the program: import Exception main = let catch = Prelude.catch in catch (print ok) print hugs 98 version 20021021 gives: ... Dependency analysis ERROR ImportAmbiguity.hs:2 - Ambiguous variable occurrence catch *** Could refer to: Prelude.catch Exception.catch ... ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: import ambiguity
On Wed, Oct 23, 2002 at 01:14:37PM -0400, Dean Herington wrote: With the program: import Exception main = let catch = Prelude.catch in catch (print ok) print hugs 98 version 20021021 gives: [...] Dependency analysis ERROR ImportAmbiguity.hs:2 - Ambiguous variable occurrence catch *** Could refer to: Prelude.catch Exception.catch It's a Hugs bug; more simply: module A where x = 1 module B where x = 4 module C where import A import B y = let x = A.x in x ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
import ambiguity
With the program: import Exception main = let catch = Prelude.catch in catch (print ok) print hugs 98 version 20021021 gives: __ __ __ __ ___ _ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2002 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: [EMAIL PROTECTED] || || Version: 20021021 _ Haskell 98 mode: Restart with command line option -98 to enable extensions Reading file /stotts2/epa1/hugs98-Oct2002/rel/lib/hugs/lib/Prelude.hs: Reading file ImportAmbiguity.hs: Reading file /stotts2/epa1/hugs98-Oct2002/rel/lib/hugs/lib/exts/Exception.hs: Reading file ImportAmbiguity.hs: Dependency analysis ERROR ImportAmbiguity.hs:2 - Ambiguous variable occurrence catch *** Could refer to: Prelude.catch Exception.catch Exception whereas GHC accepts the program. Which system is right? By the way, hugs98-Dec2001 gives: Reading file ImportAmbiguity.hs: Reading file /stotts2/epa1/hugs98-Dec2001/rel/share/hugs/lib/exts/Exception.hs: Reading file ImportAmbiguity.hs: ERROR ImportAmbiguity.hs - Entity catch imported from module Exception already defined in module Prelude ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Ambiguity
Except that this isn't actually allowed because happyReduce_1 appears in a restricted binding group, and hence can't have any context in its type. So, at this point, Hugs complains. GHC, I assume, just assigns hugsReduce_1 a monomorphic type, only to find at some later point that the list instance of Functor (and only that instance) are required to make things type check. Hugs is perhaps too eager in complaining, but it can't assign anything other than a fully polymorphic type to top-level terms, so it doesn't really have much choice. For now, the simplest fix would seem to be to use a non-overloaded map function. ... or to give an argument to happyReduce_1, which would mean it wasn't restricted any more... I think that's an accurate diagnosis. The interesting questions are: a) which compiler is implementing the language definition? b) is the langauge definition "right"? A quick look at 4.5.5 of the 1.4 report suggests that GHC is implementing the language definition and Hugs is not. The monomorphism restriction simply says you can't generalise that type variable. The report gives examples that make it clear that you are expected to be able to use the monomorphic definition at any one type in the module. Whether this "monomorphism restriction" is the "right" language spec is hotly debated. But it seems fine to me. Simon
Re: Ambiguity
Simon L Peyton Jones [EMAIL PROTECTED] writes: [Comment to Simon Marlow: Does happyReduce_1 really need *eight* type parameters? Why not output type signatures? 'fraid so: there weren't any type signatures in the grammar, and Happy can't deduce the type on its own, since it can't typecheck the code that the user wrote for the production. I can't see a way around this, without using coercions (which would remove the type safety). Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Ambiguity
[Comment to Simon Marlow:
Does happyReduce_1 really need *eight* type parameters?
Why not output type signatures?
]
I respectfully suggest that the enclosed is a bug in Hugs.
GHC gets the following type for happyReduce_1, which I think
is the correct type:
happyReduce_1 _:_ _forall_ [a b c d e f g]
= PrelBase.Int
- a
- b
- [HappyState a ([HappyAbsSyn (e - PrelBase.Double)
[(d, e - f)]
g
] - c
)
]
- [HappyAbsSyn (e - PrelBase.Double) [(d, e - f)] g]
- c ;;
This is enough to deduce that
the second type parameter for HappyAbsSyn is "list of something"
and hence enough to deduce which instance of Functor is needed.
I'm not surprised thad making action_0 self-recursive
makes the program really ambiguous, because we lose the type clue
in happyReduce_2 that the second type parameter is a list.
Simon
=
Forwarded Message
Date:Fri, 13 Feb 98 17:13:41 +0100
From:Jon Mountjoy [EMAIL PROTECTED]
To: Haskell Bugs [EMAIL PROTECTED]
Subject: Typing (Hugs/GHC)
Hello,
While playing with Happy I managed to generate a Haskell program
which compiles fine under ghc but not under Hugs. I don't know which
one is the culprit
In Hugs(January 1998), one gets
ERROR "hugs.hs" (line 32): Unresolved top-level overloading
*** Binding : happyReduce_1
*** Outstanding context : Functor b
where line 32 is the one marked -- ##
It compiles in ghc-3.00. Changing very small things, like the
line marked --- to
action_0 (6) = happyShift action_0---
then makes ghc produce a similar message:
hugs.hs:37:
Cannot resolve the ambiguous context (Functor a1Ab)
`Functor a1Ab' arising from use of `reduction', at hugs.hs:37
I am afraid that I could not make a smaller program give me this
behaviourperhaps this should be copied to hugs bugs as well?
Since the programs don't use any fancy type classes etc., one would
hope that either both compilers would accept or reject the program.
Jon
- --
- -- parser produced by Happy Version 1.5
data HappyAbsSyn t1 t2 t3
= HappyTerminal Token
| HappyErrorToken Int
| HappyAbsSyn1 t1
| HappyAbsSyn2 t2
| HappyAbsSyn3 t3
action_0 (6) = happyShift action_3---*
action_0 (1) = happyGoto action_1
action_0 (2) = happyGoto action_2
action_0 _ = happyFail
action_1 (7) = happyAccept
action_1 _ = happyFail
action_2 _ = happyReduce_1
action_3 (5) = happyShift action_4
action_3 _ = happyFail
action_4 (4) = happyShift action_6
action_4 (3) = happyGoto action_5
action_4 _ = happyFail
action_5 _ = happyReduce_2
action_6 _ = happyReduce_3
happyReduce_1 = happySpecReduce_1 1 reduction where {-- ##
reduction
(HappyAbsSyn2 happy_var_1)
= HappyAbsSyn1
(\p - let q = map (\(x,y) - (x,y p)) happy_var_1 in (10.1))
;
reduction _ = notHappyAtAll }
happyReduce_2 = happySpecReduce_3 2 reduction where {
reduction
(HappyAbsSyn3 happy_var_3)
_
(HappyTerminal (TokenVar happy_var_1))
= HappyAbsSyn2
([(happy_var_1,happy_var_3)]);
reduction _ _ _ = notHappyAtAll }
happyReduce_3 = happySpecReduce_1 3 reduction where {
reduction
(HappyTerminal (TokenInt happy_var_1))
= HappyAbsSyn3
(\p - happy_var_1);
reduction _ = notHappyAtAll }
happyNewToken action sts stk [] =
action 7 7 (error "reading EOF!") (HappyState action) sts stk []
happyNewToken action sts stk (tk:tks) =
let cont i = action i i tk (HappyState action) sts stk tks in
case tk of {
TokenInt happy_dollar_dollar - cont 4;
TokenEq - cont 5;
TokenVar happy_dollar_dollar - cont 6;
}
happyThen = \m k - k m
happyReturn = \a tks - a
myparser = happyParse
happyError ::[Token] - a
happyError _ = error "Parse error\n"
- --Here are our tokens
data Token =
TokenInt Int
| TokenVar String
| TokenEq
deriving Show
main = print (myparser [] [])
- -- $Id: HappyTemplate,v 1.8 1997/12/04 15:07:21 simonm Exp $
{-
The stack is in the following order throughout the parse:
i current token number
j another copy of this to avoid messing with the stack
tk current token semantic value
st current state
sts state stack
stk semantic stack
- -}
- -
happyParse = happyNewToken action_0 [] []
- -- All this HappyState stuff is simply because we can't have recursive
- --
