Re: [GHC] #7220: Confusing error message in type checking related to type family, fundep, and higher-rank type
#7220: Confusing error message in type checking related to type family, fundep,
and higher-rank type
--+-
Reporter: tsuyoshi | Owner: simonpj
Type: bug | Status: closed
Priority: normal | Milestone: 7.8.1
Component: Compiler (Type checker) |Version: 7.6.1-rc1
Resolution: fixed| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: typecheck/should_fail/T7220 | Blockedby:
Blocking: |Related:
--+-
Changes (by simonpj):
* status: new = closed
* testcase: = typecheck/should_fail/T7220
* resolution: = fixed
Comment:
I cannot think of any reason why it should relate the type (forall b. (C
A b, TF b ~ Y) = b) with Y. Here's why:
{{{
u :: (C A b, TF b ~ Y) = b
u = undefined
v :: X
v = (f :: (forall b. (C A b, TF b ~ Y) = b) - X) u
}}}
* GHC instanatiates the occurence of `u`, given type just `beta`, where
`beta` is a fresh unification variable. Plus constraints `(C A beta, TF
beta ~ Y)`.
* Now it tries to unify `beta` with the expected arugment type of the `(f
:: sig)` expression. This argument type is `(forall b. (C A b, TF b ~ Y)
= b)`
* So GHC (until today) would unify `beta := forall b. (C A b, TF b ~ Y)
= b`.
* So the constraint `(TF beta ~ Y)` turns into (TF (forall b. (C A b, TF
b ~ Y) = b) ~ Y)`, and that's the error you saw.
But really GHC should not have taken the third step above (at least not
without `-XImpredicativeTypes`). With the patch that fixes #6069 and
#7264 it no longer does so, yielding instead
{{{
T7220.hs:24:6:
Cannot instantiate unification variable `b0'
with a type involving foralls: forall b. (C A b, TF b ~ Y) = b
Perhaps you want -XImpredicativeTypes
In the expression: f :: (forall b. (C A b, TF b ~ Y) = b) - X
In the expression: (f :: (forall b. (C A b, TF b ~ Y) = b) - X) u
In an equation for `v':
v = (f :: (forall b. (C A b, TF b ~ Y) = b) - X) u
}}}
which isn't fantastic but is perhaps less confusing than before.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7220#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] #7220: Confusing error message in type checking related to type family, fundep, and higher-rank type
#7220: Confusing error message in type checking related to type family, fundep, and higher-rank type +--- Reporter: tsuyoshi | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.1-rc1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | +--- Changes (by igloo): * owner: = simonpj * difficulty: = Unknown * milestone: = 7.8.1 Comment: Simon, could you take a look at this please? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7220#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] #7220: Confusing error message in type checking related to type family, fundep, and higher-rank type
#7220: Confusing error message in type checking related to type family, fundep,
and higher-rank type
--+-
Reporter: tsuyoshi | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler (Type checker)
Version: 7.6.1-rc1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
(This is related to, but different from, the message which I posted to
glasgow-haskell-users mailing list: http://www.haskell.org/pipermail
/glasgow-haskell-users/2012-September/022815.html.)
GHC 7.6.1-rc1 (7.6.0.20120810; 64-bit Windows) rejects the attached code
(Test2.hs) with the following error message:
{{{
Test2.hs:24:52:
Couldn't match expected type `Y'
with actual type `TF (forall b. (C A b, TF b ~ Y) = b)'
In the first argument of `f ::
(forall b. (C A b, TF b ~ Y) = b) - X',
namely
`u'
In the expression: (f :: (forall b. (C A b, TF b ~ Y) = b) - X) u
In an equation for `v':
v = (f :: (forall b. (C A b, TF b ~ Y) = b) - X) u
}}}
I am not sure whether the code is supposed to be accepted or rejected, but
even if it is correct to reject the code, this error message does not look
right to me. If I am not mistaken, the error message is saying that the
type checker expects the argument of `(f :: (forall b. (C A b, TF b ~ Y)
= b) - X)` to have type `Y`, but I cannot think of any reason why it
should relate the type `(forall b. (C A b, TF b ~ Y) = b)` with `Y`.
The same code is available also at https://gist.github.com/3606856.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7220
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] #7220: Confusing error message in type checking related to type family, fundep, and higher-rank type
#7220: Confusing error message in type checking related to type family, fundep, and higher-rank type --+- Reporter: tsuyoshi | Owner: Type: bug | Status: new Priority: normal| Component: Compiler (Type checker) Version: 7.6.1-rc1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- Comment(by tsuyoshi): When I posted this report, I had been overlooking `TF` in the “actual type” part of the error message. Now the error message at least makes some sense. (Although I do not fully understand why the code is rejected in the first place, I think that I have to understand the algorithm used by the type checker to understand this.) I am not sure whether this bug report still makes sense or not. If not, please close it. Sorry about this. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7220#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] #5763: Confusing error message
#5763: Confusing error message -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.2.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: indexed-types/should_fail/T5763 Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = simonpj -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5763#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
[GHC] #5763: Confusing error message
#5763: Confusing error message
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 7.6.1
Component: Compiler | Version: 7.2.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase: indexed-types/should_fail/T4272
Blockedby:|Blocking:
Related:|
-+--
For test `indexed-types/should_fail/T4272` we get this type error
{{{
T4272.hs:11:16:
Occurs check: cannot construct the infinite type:
x0 = TermFamily x0 x0
Expected type: TermFamily x0 x0
Actual type: TermFamily a a
In the first argument of `prune', namely `t'
In the expression: prune t (terms (undefined :: TermFamily a a))
In an equation for `laws':
laws t = prune t (terms (undefined :: TermFamily a a))
}}}
It's not at all obvious why unifying `(TermFamily x0 x0)` with
`(TermFamily a a)` should yield an occurs check. Especially as
`TermFamily` is a type function with arity 1, and `x0` is a unification
variable. So the natural way to solve this constraint would be to unify
`x0` with `a`, and then the constraint is satisfied.
What goes wrong is that there is ''another'' insolube constraint (which is
also reported):
{{{
T4272.hs:11:19:
Could not deduce (a ~ TermFamily x0 x0)
from the context (TermLike a)
bound by the type signature for
laws :: TermLike a = TermFamily a a - b
at T4272.hs:11:1-54
`a' is a rigid type variable bound by
the type signature for laws :: TermLike a = TermFamily a a - b
at T4272.hs:11:1
In the return type of a call of `terms'
In the second argument of `prune', namely
`(terms (undefined :: TermFamily a a))'
In the expression: prune t (terms (undefined :: TermFamily a a))
}}}
The constraint solver finds this latter constraint, can't solve it, ''but
still uses it to simplify the first one'', by substituting `(TermFamily x0
x0)` for `a`; and that is what gives the occurs check error.
I don't think that we should use ''insoluble'' constraints to rewrite
unsolved constraints. But it's delicate, so I am not trying to fiddle
right now. Hence making this ticket.
(Incidentally, it's not a regression; it's been like this forever.)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5763
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] #5763: Confusing error message
#5763: Confusing error message -+-- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.2.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: indexed-types/should_fail/T4272 Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * priority: normal = high Comment: I'll make it high priority to make sure I look at it for 7.6. But it's not really that serious. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5763#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] #5763: Confusing error message
#5763: Confusing error message -+-- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.2.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: indexed-types/should_fail/T5763 Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * testcase: indexed-types/should_fail/T4272 = indexed- types/should_fail/T5763 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5763#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
Re: [GHC] #4099: Slighlty confusing error message with data families
#4099: Slighlty confusing error message with data families
--+-
Reporter: rl | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler |Version: 6.13
Resolution: fixed| Keywords:
Difficulty: | Os:
Unknown/Multiple
Testcase: indexed-types/should_fail/T4099 | Architecture:
Unknown/Multiple
Failure: None/Unknown |
--+-
Changes (by simonpj):
* status: new = closed
* testcase: = indexed-types/should_fail/T4099
* resolution: = fixed
Comment:
Yes good point. Fixed by
{{{
Mon May 31 15:04:13 BST 2010 simo...@microsoft.com
* Fix Trac #4099: better error message for type functions
Now we only want about T is a type function and might not be
injective when matchin (T x) against (T y), which is the case
that is really confusing.
M ./compiler/typecheck/TcTyFuns.lhs -14 +9
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4099#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] #4099: Slighlty confusing error message with data families
#4099: Slighlty confusing error message with data families
-+--
Reporter: rl| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 6.13 |Keywords:
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Example code:
{{{
data family T a
foo :: T a - a
foo (Just x) = x
}}}
Error message:
{{{
Couldn't match expected type `T a' against inferred type `Maybe a1'
NB: `T' is a type function
In the pattern: Just x
In the definition of `foo': foo (Just x) = x
}}}
Calling `T` a type function is confusing, I had to double check that I
hadn't accidentally declared it as a type family. I would
* call these things type families and data families in messages and
* omit the message for data families altogether because it doesn't
matter that `T` is one in this case.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4099
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] #2900: Confusing error message for monadic function with wrong number of arguments
#2900: Confusing error message for monadic function with wrong number of arguments +--- Reporter: tim |Owner: Type: bug | Status: new Priority: normal |Milestone: _|_ Component: Compiler (Type checker) | Version: 6.10.1 Severity: minor| Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | +--- Changes (by igloo): * milestone: = _|_ -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2900#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
Re: [GHC] #2900: Confusing error message for monadic function with wrong number of arguments
#2900: Confusing error message for monadic function with wrong number of arguments +--- Reporter: tim |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: minor| Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | +--- Changes (by simonpj): * cc: chak (added) * difficulty: = Unknown Comment: Good example! Sadly, it's quite awkward to fix. Here's what is happening. * GHC tries to make the type `Int - m ()` look like `ty1 - ty2 - ty3` (to match the syntactic form of the LHS. * It's ''possible'' that the context `(MonadIO m)` might have, as a superclass the equality `m ~ (-) Int`. In that case we'd get `ty2 = Int`, `ty3 = ()`. * Because `m` might be elucidated by the context, GHC can't reject the result type `(m ())` right away. Instead it invents a fresh type variable alpha, and generates the contraint that `(m ~ (-) alpha)`, leaving the constraint to be solved later. * Now we go on to the RHS, and that gives a type error. What we really want here is to solve the first constraint eagerly, and proceed only if it succeeds. The type checker isn't set up to do that at the moment, but this is an interesting example to bear in mind, thank you. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2900#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] #2900: Confusing error message for monadic function with wrong number of arguments
#2900: Confusing error message for monadic function with wrong number of
arguments
-+--
Reporter: tim | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler (Type checker)
Version: 6.10.1| Severity: minor
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
If I compile the following code:
{{{
import Control.Monad.State
foo :: MonadIO m = Int - m ()
foo x y = return ()
}}}
I get the error message:
{{{
bug.hs:6:10:
Couldn't match expected type `()' against inferred type `m ()'
In the expression: return ()
In the definition of `foo': foo x y = return ()
}}}
On the other hand, if I change foo's type signature to:
{{{
foo :: Int - IO ()
}}}
I get the more helpful:
{{{
bug.hs:6:0:
The equation(s) for `foo' have two arguments,
but its type `Int - IO ()' has only one
}}}
It would be good if the second error message appeared in the first case as
well.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2900
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] #2371: `ghci` prints confusing error message if using :m + instead of :load
#2371: `ghci` prints confusing error message if using :m + instead of :load
-+--
Reporter: bos | Owner:
Type: bug | Status: closed
Priority: normal | Milestone: 6.10 branch
Component: GHCi |Version: 6.8.2
Severity: normal | Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
I added the above explanation (more or less) to the docs.
{{{
Fri Jul 11 13:00:46 BST 2008 Simon Marlow [EMAIL PROTECTED]
* #2371: try to explain the difference between :module and :load
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2371#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] #2371: `ghci` prints confusing error message if using :m + instead of :load
#2371: `ghci` prints confusing error message if using :m + instead of :load
+---
Reporter: bos | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 6.8.2|Severity: normal
Keywords: |Testcase:
Architecture: Unknown | Os: Unknown
+---
`ghci` seems to treat the `:module +` command differently from
`:load`, in a way that I do not understand.
If I try to load a module in the current directory, this fails:
{{{
Prelude :m +BloomFilter
module main:BloomFilter is not loaded
Prelude :! ls BloomFilter.hs
BloomFilter.hs
}}}
But this succeeds:
{{{
Prelude :load BloomFilter
Ok, modules loaded: BloomFilter, BloomFilter.Mutable,
BloomFilter.Internal.
}}}
I don't have a problem with the difference in behaviour, but it doesn't
appear to be documented. I thus don't really know why it occurs (though I
can guess), which means that I can't clearly explain it as a gotcha in the
book.
Also, the the `module main:BloomFilter is not loaded` error message is
baffling: since it doesn't tell me what is actually wrong or why, I had no
idea what was occurring until I remembered the difference in behaviour
between the two commands.
Turning on `:set -v` doesn't shed any more light on the failure of `:m
+`, so this is that much more difficult to figure out.
In general, the error messages from GHC and `ghci` are useful. If you
could fix this one up, that would be great! Thanks.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2371
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] #1888: Slightly confusing error message for duplicate NOINLINE pragmas
#1888: Slightly confusing error message for duplicate NOINLINE pragmas ---+ Reporter: tim| Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) |Version: 6.8.1 Severity: trivial| Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rnfail048 | Architecture: Unknown Os: Unknown| ---+ Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1888#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] #1888: Slightly confusing error message for duplicate NOINLINE pragmas
#1888: Slightly confusing error message for duplicate NOINLINE pragmas
---+
Reporter: tim| Owner: igloo
Type: merge | Status: new
Priority: normal | Milestone:
Component: Compiler (Parser) |Version: 6.8.1
Severity: trivial| Resolution:
Keywords: | Difficulty: Unknown
Testcase: rnfail048 | Architecture: Unknown
Os: Unknown|
---+
Changes (by simonpj):
* testcase: = rnfail048
* owner: simonpj = igloo
* type: bug = merge
Comment:
Fixed. Might as well merge the patch
{{{
Wed Nov 14 10:47:01 GMT 2007 [EMAIL PROTECTED]
* FIX Trac 1888; duplicate INLINE pragmas
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1888#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] #1888: Slightly confusing error message for duplicate NOINLINE pragmas
#1888: Slightly confusing error message for duplicate NOINLINE pragmas
--+-
Reporter: tim| Owner:
Type: bug| Status: new
Priority: normal | Milestone:
Component: Compiler (Parser) | Version: 6.8.1
Severity: trivial|Keywords:
Difficulty: Unknown|Testcase:
Architecture: Unknown| Os: Unknown
--+-
I had some code with two NOINLINE pragmas for the same declaration:
{{{
{-# NOINLINE foo #-}
{-# NOINLINE foo #-}
}}}
and I got the error message:
{{{
UntypedEval.hs:206:0:
Duplicate NOINLINENEVER pragma:
UntypedEval.hs:206:0-19: {-# NOINLINENEVER foo #-}
UntypedEval.hs:202:0-19: {-# NOINLINENEVER foo #-}
}}}
Since I wrote {{{NOINLINE}}}, I think the error message should say
{{{NOINLINE}}}. It's not a very big deal.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1888
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] #1310: confusing error message when trying to give a type-signature to an imported symbol
#1310: confusing error message when trying to give a type-signature to an
imported
symbol
-+--
Reporter: Isaac Dupree |Owner:
Type: bug | Status: closed
Priority: normal|Milestone:
Component: Compiler | Version: 6.6.1
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
-+--
Changes (by simonpj):
* resolution: = fixed
* status: new = closed
Comment:
Good point. I've improved the error messages. For imports:
{{{
Foo.hs:4:11:
Misplaced type signature: putStrLn :: String - IO ()
You cannot give a type signature for an imported value
}}}
For locals:
{{{
Foo.hs:4:11:
Misplaced type signature: p :: String - IO ()
The type signature must be given where `p' is declared
}}}
Thanks for the suggestion
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1310
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] #1310: confusing error message when trying to give a type-signature to an imported symbol
#1310: confusing error message when trying to give a type-signature to an
imported
symbol
---+
Reporter: Isaac Dupree | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.6.1
Severity: normal| Keywords:
Difficulty: Unknown | Os: Unknown
Testcase:| Architecture: Unknown
---+
{{{
import Prelude(putStrLn,String,IO)
main = putStrLn ha --works fine; putStrLn _is_ in (this) scope
}}}
{{{
putStrLn :: String - IO () --produces ghc error: Not in scope: `putStrLn'
}}}
{{{
Prelude.putStrLn :: String - IO () --produces ghc error: Invalid type
signature
}}}
I think an error message more like type signatures can't be given to
functions(or non-function data) not defined in the same module in both
cases would be clearer. Not sure what the right phrase is for
functions(or non-function data), symbols,?
{{{
main = putStrLn ha
where p :: String - IO ()
p x = putStrLn x
--produces ghc error: Misplaced type signature: p :: String - IO ()
}}}
which shows a little more understanding in that case... If someone didn't
understand how that style of type-signature could only appear parallel to
a definition, I'm not sure how helpful it is.
{{{
main = putStrLn ha
where putStrLn :: String - IO ()
--produces ghc error for the second line: Not in scope: `putStrLn'
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1310
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-Bugs-681062 ] Confusing Error Message if package-name is omitted
Bugs item #681062, was opened at 2003-02-05 17:09 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=681062group_id=8032 Category: Driver Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Wolfgang Thaller (wthaller) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing Error Message if package-name is omitted Initial Comment: I compiled a library as a GHC package without adding the appropriate package-name flag to the ghc command line. When trying to compile a module that used the package, ghc complained that it couldn't find package quot;Mainquot;. This happens with the HEAD. With GHC 5.04 it (seemingly) was no problem to leave out the -package-name specifier. Why is the -package-name flag needed at all? -- Comment By: Simon Marlow (simonmar) Date: 2004-11-25 13:57 Message: Logged In: YES user_id=48280 -package-name will be gone in 6.4 (yay!), so I can close this bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=681062group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: confusing error message
Good point. Error message improved, regression test added. Thanks for the suggestion Simon | -Original Message- | From: Dean Herington [mailto:[EMAIL PROTECTED]] | Sent: 05 February 2003 19:14 | To: [EMAIL PROTECTED] | Subject: confusing error message | | buzzard(118)% cat Bug5.hs | import Control.Monad.State | data S = S Int | newtype M a = M (StateT S IO a) | deriving (Monad) | | main = return () | buzzard(119)% ghc -c Bug5.hs | | Bug5.hs:3: | Can't make a derived instance of `Monad M' | (too hard for cunning newtype deriving) | When deriving instances for type `M' | buzzard(120)% ghc --version | The Glorious Glasgow Haskell Compilation System, version 5.04.2 | | | The real problem above is that I forgot to enable extensions. It would | be helpful if the error message indicated that as the problem. | | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-681062 ] Confusing Error Message if package-name is omitted
Bugs item #681062, was opened at 2003-02-05 18:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=681062group_id=8032 Category: Driver Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Thaller (wthaller) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing Error Message if package-name is omitted Initial Comment: I compiled a library as a GHC package without adding the appropriate package-name flag to the ghc command line. When trying to compile a module that used the package, ghc complained that it couldn't find package Main. This happens with the HEAD. With GHC 5.04 it (seemingly) was no problem to leave out the -package-name specifier. Why is the -package-name flag needed at all? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=681062group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
confusing error message
buzzard(118)% cat Bug5.hs import Control.Monad.State data S = S Int newtype M a = M (StateT S IO a) deriving (Monad) main = return () buzzard(119)% ghc -c Bug5.hs Bug5.hs:3: Can't make a derived instance of `Monad M' (too hard for cunning newtype deriving) When deriving instances for type `M' buzzard(120)% ghc --version The Glorious Glasgow Haskell Compilation System, version 5.04.2 The real problem above is that I forgot to enable extensions. It would be helpful if the error message indicated that as the problem. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
confusing error message
ghc-4.04 gives the following confusing error message: compiling with ghc-4.04 -fglasgow-exts -c Test.hs Test.hs:8: None of the type variable(s) in the constraint `Eq a' appears in the type `Set a - Set a - Set a' In the type signature for `unionSets' Compilation had errors module Test where unionSetB :: Eq a = Set a - Set a - Set a unionSetB (s1 :: Set a) s2 = unionSets s1 s2 where unionSets :: Eq a = Set a - Set a - Set a unionSets a b = a Ok, I know why this happens, because a is no longer free in unionSets because of the pattern signature, but initially it confused me looking at it trying to work out why a /= a. (Incidently hugs accepts this code without any complaints) Meurig
Re: Confusing error message in case of layout-related syntax erro r
Simon wrote: I know about this one, but haven't got around to fixing it yet. The parse error is on a semicolon generated by the layout system, as you probably guessed, which is why there's no token available to print in the error message. Any thoughts on what a suitable error message should be? I'd thought something along the lines of Main.hs:3: parse error on input ';' (inserted by layout) My students find this kind of error message (Hugs says "unexpected ';'") the most confusing and frustrating thing in all of Haskelldom. If you know that the (virtual) semicolon has been inserted by layout, how about a message like: Main.hs:3: indentation error or Main.hs:3: incorrect indentation or Main.hs:3: parse error due to incorrect indentation (I think the term "indentation" means more to them than "layout", but there might be good reasons to say "layout error" instead). Mark. Dr Mark Utting, Senior Lecturer Department of Computer Science School of Computing and Mathematical Sciences The University of Waikato Tel: +64 7 838 4791 Private Bag 3105Fax: +64 7 838 4155 HamiltonEmail: [EMAIL PROTECTED] New Zealand Web: http://www.cs.waikato.ac.nz/~marku
RE: Confusing error message in case of layout-related syntax error
Main.hs:3: parse error on input ';' (inserted by layout) Incomplete expression on previous line or incorrect indentation of the current line. I think Manuel's suggestion is a definite improvement here. For interest, another Haskell compiler, nhc98, gives the message 4:5 Found ;' but expected one of ) , which is perhaps a little bit cryptic, but could be improved to 4:5 Found end-of-definition but expected one of ) , which I think is very clear. Regards, Malcolm
RE: Confusing error message in case of layout-related syntax erro r
For foo = let x = (1, 2 y = 3 in fst x + y GHC 4.04 gives me Main.hs:3: parse error on input `' Interesting, but not very informative ;-) I know about this one, but haven't got around to fixing it yet. The parse error is on a semicolon generated by the layout system, as you probably guessed, which is why there's no token available to print in the error message. Any thoughts on what a suitable error message should be? I'd thought something along the lines of Main.hs:3: parse error on input ';' (inserted by layout) re: the multi-line string literals, this one should be easier to fix. I'll take a look at it today. Cheers, Simon
Confusing error message in case of layout-related syntax error
For foo = let x = (1, 2 y = 3 in fst x + y GHC 4.04 gives me Main.hs:3: parse error on input `' Interesting, but not very informative ;-) I also have the feeling that GHC is sometimes off by a couple of lines when reporting errors in bigger modules - but I don't have a good example yet. Manuel
Re: Confusing error message
I encountered a confusing error message, which you can reproduce with type P a = Maybe a instance Monad P where (=) = error "foo" return = error "bar" I get bug.hs:5: `P' should have 1 argument, but has been given 0 . Would it be better if it said Type synonym constructor P should have 1 argument, but has been given 0 Haskell requires that type synonyms are never partially applied; that's what's being complained about here. If you did fully apply it, GHC 3.1 (without -fglasow-exts) would then complain about making an instance of a type synonym. At the moment, though, it trips over the mal-formed type expression first. That's what I guessed, but I reckon that it may be a bit difficult to spot for people who are not so familiar with the details of constructor classes. But, maybe it is too much fuzz to check for this special situation explicitly. I wonder whether it would be helpful to add a comment like (or if this is a instance declaration, type synonyms are not allowed) to the message. Manuel
Confusing error message
Hi GHC-Developers! I encountered a confusing error message, which you can reproduce with type P a = Maybe a instance Monad P where (=) = error "foo" return = error "bar" I get bug.hs:5: `P' should have 1 argument, but has been given 0 . with ** ghc 2.05 ** (maybe things changed in the meanwhile.) The problem in the program is clear, we cannot have an instance of a type synonym, but that's far from obvious from the error message. Cheers, Manuel
Re: Confusing error message
I encountered a confusing error message, which you can reproduce with type P a = Maybe a instance Monad P where (=) = error "foo" return = error "bar" I get bug.hs:5: `P' should have 1 argument, but has been given 0 . Would it be better if it said Type synonym constructor P should have 1 argument, but has been given 0 Haskell requires that type synonyms are never partially applied; that's what's being complained about here. If you did fully apply it, GHC 3.1 (without -fglasow-exts) would then complain about making an instance of a type synonym. At the moment, though, it trips over the mal-formed type expression first. Does that make sense? Any suggestions for improving the error message in a way that would have made sense to you at the time? Simon
