Re: cascading type errors in ghc
On 6 Aug 2013, at 20:03, Evan Laforge wrote: I don't know how others like to work, but I like when a compiler bails early, because I fix errors one at a time, and I search for the easiest looking ones before worrying about the complicated looking ones. With C compilers, it is often the case that only the first error is real, and the subsequent errors are consequences of not being able to recover from the first one. However, one of the really nice things about GHC is that the list of type errors is complete and coherent. I often start at the bottom of the list and work my way up fixing them in a single pass (upwards, in order to give myself the best chance that the line numbers are still correct after I have fixed the later errors). There are not many compilers you can do that with, and I like it when I can. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cascading type errors in ghc
On Sun, Jul 28, 2013 at 9:01 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Giving good type error messages is tricky! Indeed, and I'm fully aware this is a Hard Problem. You get different behaviour for literals because 0 has type (forall a. Num a = a), whereas you declared x1 to have type Int. GHC could have additionally said Can't find an instance for Num Bool, but it suppresses such errors if there are more serious ones at hand. Hence the difference you observed. Previous GHCs would often bale out altogether if they tried to unify Int with Bool, and recover at some outer point. That's good for not getting lots of errors, but it might suppress genuinely separate errors. Nowadays we gather all the unsolved constraints without an exception-style bale-out, which probably accounts for you seeing more errors. Yeah, that makes a lot of sense, thanks for the explanation. I don't know how others like to work, but I like when a compiler bails early, because I fix errors one at a time, and I search for the easiest looking ones before worrying about the complicated looking ones. The good news is that error generation is all in one module TcErrors.lhs, so it's easy to adjust these things. For example, given a nearby bunch of errors, you could suppress all but one. I don't know whether that would on balance make things better or not. But it's certainly easy to experiment (if you build yourself a GHC). Maybe we could do better with some heuristics, e.g. categorize errors into simple and advanced, and have simple errors suppress advanced ones. This already happens to an extent: syntax error will suppress unbound name errors, which will suppress type errors, which will suppress typeclass instance errors. These rough categorizations sort of come for free because of the layers in ghc itself, but nonetheless they have a nice effect where you fix problems in layers from simple to complicated. I like it because it matches my simple-complicated preference. Of course that just moves the problem over to telling simple from advanced, so you'd probably have to look at an error from several different angles to try to discover a simpler interpretation. I suppose I shouldn't wade further in here unless I'm prepared to quit my day job and go be an intern at GHC HQ to implement a research project :) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: cascading type errors in ghc
Giving good type error messages is tricky! You get different behaviour for literals because 0 has type (forall a. Num a = a), whereas you declared x1 to have type Int. GHC could have additionally said Can't find an instance for Num Bool, but it suppresses such errors if there are more serious ones at hand. Hence the difference you observed. Previous GHCs would often bale out altogether if they tried to unify Int with Bool, and recover at some outer point. That's good for not getting lots of errors, but it might suppress genuinely separate errors. Nowadays we gather all the unsolved constraints without an exception-style bale-out, which probably accounts for you seeing more errors. The good news is that error generation is all in one module TcErrors.lhs, so it's easy to adjust these things. For example, given a nearby bunch of errors, you could suppress all but one. I don't know whether that would on balance make things better or not. But it's certainly easy to experiment (if you build yourself a GHC). Simon | -Original Message- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] | On Behalf Of Evan Laforge | Sent: 27 July 2013 20:36 | To: GHC users | Subject: cascading type errors in ghc | | I frequently see one logical mistake turn into many type errors in | ghc. Of course in general one logical mistake to a human and a type | checker can be completely different things, so that's not surprising. | The thing is, I feel like I started seeing more with the upgrade to | ghc 7.6 (or was it 7.4?) a while back, which I guess coincides with a | big typechecker overhaul. So I tracked down a specific example, | though I haven't checked if this gives different results in older | ghcs: | | complicated :: Bool - Int - (Double - Double) | - Int - Char - Int - Char - () | complicated _ _ _ _ _ _ _ = () | | t0 = complicated 0 id x1 y1 x1 y1 | where | x1 :: Int | x1 = 0 | y1 :: Char | y1 = 'a' | | In this case, the call to complicated is missing the initial Bool. In | ghci the above gives 5 separate type errors, for the 2nd, 3rd, 4th, | 5th, and 6th arguments. The curious thing is, if I replace x1 and y1 | with their values: | | t0 = complicated 0 id 0 'a' 0 'a' | | I'm now down to only 3 type errors, for 2nd, 4th, and 6th args. | | So I'm just curious: what's the difference between the where-bound | stuff and literals? Also, why don't I get an error that 0 isn't a | Bool? Or I suppose, that there's no instance Integral Bool? | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
cascading type errors in ghc
I frequently see one logical mistake turn into many type errors in ghc. Of course in general one logical mistake to a human and a type checker can be completely different things, so that's not surprising. The thing is, I feel like I started seeing more with the upgrade to ghc 7.6 (or was it 7.4?) a while back, which I guess coincides with a big typechecker overhaul. So I tracked down a specific example, though I haven't checked if this gives different results in older ghcs: complicated :: Bool - Int - (Double - Double) - Int - Char - Int - Char - () complicated _ _ _ _ _ _ _ = () t0 = complicated 0 id x1 y1 x1 y1 where x1 :: Int x1 = 0 y1 :: Char y1 = 'a' In this case, the call to complicated is missing the initial Bool. In ghci the above gives 5 separate type errors, for the 2nd, 3rd, 4th, 5th, and 6th arguments. The curious thing is, if I replace x1 and y1 with their values: t0 = complicated 0 id 0 'a' 0 'a' I'm now down to only 3 type errors, for 2nd, 4th, and 6th args. So I'm just curious: what's the difference between the where-bound stuff and literals? Also, why don't I get an error that 0 isn't a Bool? Or I suppose, that there's no instance Integral Bool? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: runghc -fdefer-type-errors
On Mon, Mar 11, 2013 at 9:33 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: On 03/11/2013 07:04 PM, Simon Peyton-Jones wrote: Aha. It is indeed true that ghc -fdefer-type-errors -w does not suppress the warnings that arise from the type errors; indeed there is no current way to do so. How to do that? To be kosher there should really be a flag to switch off those warnings alone, perhaps -fno-warn-type-errors So then -fwarn-type-errors is on by default, but is only relevant when -fdefer-type-errors is on. Once -fdefer-type-errors is on, -fno-warn-type-errors and -fwarn-type-errors suppress or enable the warnings. -w would then include -fno-warn-type-errors. GCC has a concept -Werror=unused-variable for example: each warning can be disabled, a warning, or an error. If GHC had that, we could have type-errors be a warning whose default state is -Werror. That's cleaner in a certain way, but it also seems fishy. Just throwing the idea out there. I don't know which way GHC would like to go, but I can comment on the GCC feature as I have direct experience here. For a long time I was very reluctant to the fine-grained warning categories; rather I preferred a much coarser grained warning categories; my thinking was that warnings or questionable coding practices come in cluster (I still do.) Remember that the more nobs you give user to control the compiler, the larger your test matrix becomes and the higher is the probability of untested and/or incoherent compiler switch combinations. However, several fellow GCC developers felt otherwise -- many citing the pressure of the competition (e.g. icc, clang, etc.), so I eventually gave in but under the condition that we still maintain the coarse-grained warning categories (e.g. -Wall, -Wextra, etc.) and display in the diagnostics how users are to turn off a specific warning they did not like. I suspect that if users frequently need to turn off a warning, then that warning should probably be off by default. Most users rarely want to specify long (and arcane) command lines; very few want to litter their otherwise pretty programs with lines of pragmas (no matter how much effort was spent in designing the syntax.) -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
runghc -fdefer-type-errors
Hello, Doesn't runghc support the -fdefer-type-errors option? Consider this code: module Main where main :: IO () main = do -- putStrLn は文字列を取る putStrLn Hello, world! putStrLn 1 -- 型エラー If I use runghc with -fdefer-type-errors, Hello, world! is not printed. Is this a bug? If this behavior is intended, I would like to change it. If GHC can run code like dynamically typed languages, it would be appealing to new Haskell programmers from their community. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: runghc -fdefer-type-errors
When I ran this code (ghc 7.6.1), I did get the Hello, world! printout. That
line was sandwiched between the compile-time warning from the type error and
the run-time exception from the type error, but the output was there:
09:24:28 ~/temp runghc Scratch.hs
Scratch.hs:5:12: Warning:
No instance for (Num String) arising from the literal `1'
Possible fix: add an instance declaration for (Num String)
In the first argument of `putStrLn', namely `1'
In a stmt of a 'do' block: putStrLn 1
In the expression:
do { putStrLn Hello, world;
putStrLn 1 }
Hello, world
Scratch.hs: Scratch.hs:5:12:
No instance for (Num String) arising from the literal `1'
Possible fix: add an instance declaration for (Num String)
In the first argument of `putStrLn', namely `1'
In a stmt of a 'do' block: putStrLn 1
In the expression:
do { putStrLn Hello, world;
putStrLn 1 }
(deferred type error)
It's easier to see with `runghc Scratch.hs 2 /dev/null` which prints only the
Hello, world! Oddly, passing flag -w doesn't suppress the warning, so I don't
think there's a way to turn it off.
Richard
On Mar 11, 2013, at 3:45 AM, Kazu Yamamoto (山本和彦) k...@iij.ad.jp wrote:
Hello,
Doesn't runghc support the -fdefer-type-errors option?
Consider this code:
module Main where
main :: IO ()
main = do
-- putStrLn は文字列を取る
putStrLn Hello, world!
putStrLn 1 -- 型エラー
If I use runghc with -fdefer-type-errors, Hello, world! is not
printed. Is this a bug?
If this behavior is intended, I would like to change it. If GHC can
run code like dynamically typed languages, it would be appealing to
new Haskell programmers from their community.
--Kazu
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: runghc -fdefer-type-errors
Hi, When I ran this code (ghc 7.6.1), I did get the Hello, world! printout. That line was sandwiched between the compile-time warning from the type error and the run-time exception from the type error, but the output was there: Thank you for letting me know this. I'm also using GHC 7.6.1. I should try to find why the incorrect behavior happens in my environment. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: runghc -fdefer-type-errors
Excerpts from Simon Peyton-Jones's message of Mon Mar 11 16:04:31 -0700 2013: Aha. It is indeed true that ghc -fdefer-type-errors -w does not suppress the warnings that arise from the type errors; indeed there is no current way to do so. How to do that? To be kosher there should really be a flag to switch off those warnings alone, perhaps -fno-warn-type-errors So then -fwarn-type-errors is on by default, but is only relevant when -fdefer-type-errors is on. Once -fdefer-type-errors is on, -fno-warn-type-errors and -fwarn-type-errors suppress or enable the warnings. -w would then include -fno-warn-type-errors. Is that a design everyone would like? If so, woudl someone like to open a ticket, implement it, update the documentation, and send a patch? SGTM. Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: runghc -fdefer-type-errors
When I ran this code (ghc 7.6.1), I did get the Hello, world! printout. That line was sandwiched between the compile-time warning from the type error and the run-time exception from the type error, but the output was there: Thank you for letting me know this. I'm also using GHC 7.6.1. I should try to find why the incorrect behavior happens in my environment. I noticed that -- is necessary. runghc -- -fdefer-type-errors Main.hs --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: runghc -fdefer-type-errors
On 03/11/2013 07:04 PM, Simon Peyton-Jones wrote: Aha. It is indeed true that ghc -fdefer-type-errors -w does not suppress the warnings that arise from the type errors; indeed there is no current way to do so. How to do that? To be kosher there should really be a flag to switch off those warnings alone, perhaps -fno-warn-type-errors So then -fwarn-type-errors is on by default, but is only relevant when -fdefer-type-errors is on. Once -fdefer-type-errors is on, -fno-warn-type-errors and -fwarn-type-errors suppress or enable the warnings. -w would then include -fno-warn-type-errors. GCC has a concept -Werror=unused-variable for example: each warning can be disabled, a warning, or an error. If GHC had that, we could have type-errors be a warning whose default state is -Werror. That's cleaner in a certain way, but it also seems fishy. Just throwing the idea out there. -Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC] #7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault
#7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault --+- Reporter: parcs| Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler |Version: 7.6.1 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: th/T7276, th/T7276b | Blockedby: Blocking: |Related: --+- Changes (by igloo): * status: merge = closed * resolution: = fixed Comment: Merged as 50837615c7e1d1d6b703e99ee7fd8fcf0bfee30c and da26f6c38c22158f698ec75d910ebe4a61923d25 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7276#comment:10 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] #7294: -fdefer-type-errors doesn't produce a warning
#7294: -fdefer-type-errors doesn't produce a warning --+- Reporter: Feuerbach| Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) |Version: 7.6.1 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Difficulty: Unknown Testcase: gadt/T7293, T7294| Blockedby: Blocking: |Related: --+- Changes (by igloo): * status: merge = closed Comment: Not worth merging, I think -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7294#comment:10 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] #7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault
#7276: -fdefer-type-errors allows the types of quotations to be coerced, causing
segmentation fault
-+--
Reporter: parcs | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.6.2
Component: Compiler|Version: 7.6.1
Resolution: | Keywords:
Os: Unknown/Multiple| Architecture: Unknown/Multiple
Failure: Compile-time crash | Difficulty: Unknown
Testcase: th/T7276| Blockedby:
Blocking: |Related:
-+--
Comment(by simonpj@…):
commit 0b2a6a0580c34e4fcb77a67719d77b358bb4d69d
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Oct 15 15:07:16 2012 +0100
Wrap a bracket quotation in a coercion that makes it have the right
type
This is the right fix to Trac #7276 (part 2), which makes the
interaction with -fdefer-type-errors and TH work properly.
compiler/typecheck/TcSplice.lhs | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7276#comment:8
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] #7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault
#7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault --+- Reporter: parcs| Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.6.2 Component: Compiler |Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: th/T7276, th/T7276b | Blockedby: Blocking: |Related: --+- Changes (by simonpj): * status: new = merge * testcase: th/T7276 = th/T7276, th/T7276b Comment: I've added a regression test for the second bug too. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7276#comment:9 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] #7294: -fdefer-type-errors doesn't produce a warning
#7294: -fdefer-type-errors doesn't produce a warning --+- Reporter: Feuerbach| Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) |Version: 7.6.1 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Difficulty: Unknown Testcase: gadt/T7293, T7294| Blockedby: Blocking: |Related: --+- Changes (by igloo): * milestone: = 7.6.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7294#comment:9 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] #7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault
#7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault -+-- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler|Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: th/T7276| Blockedby: Blocking: |Related: -+-- Changes (by igloo): * status: merge = new * milestone: = 7.6.2 Comment: Let's fix the new problems before merging. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7276#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] #7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault
#7276: -fdefer-type-errors allows the types of quotations to be coerced, causing
segmentation fault
-+--
Reporter: parcs | Owner:
Type: bug | Status: merge
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Compile-time crash
Difficulty: Unknown |Testcase: th/T7276
Blockedby:|Blocking:
Related:|
-+--
Comment(by parcs):
I think I found the underlying issue: when the inferred type and actual
type of a TH bracket don't match, the TH bracket does not get replaced
with a call to `error`. Instead, the bracket is just coerced to whatever
type it's expected to be, e.g.:
{{{
let a = [| True |] :: Int
a
1099511628032
}}}
instead of:
{{{
let a = [| True |] :: Int
a
*** Exception: interactive:2:9:
Couldn't match type `Language.Haskell.TH.Syntax.Q
...
(deferred type error)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7276#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] #7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault
#7276: -fdefer-type-errors allows the types of quotations to be coerced, causing
segmentation fault
-+--
Reporter: parcs | Owner:
Type: bug | Status: merge
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Compile-time crash
Difficulty: Unknown |Testcase: th/T7276
Blockedby:|Blocking:
Related:|
-+--
Comment(by parcs):
It looks like you can still trigger a segfault if you bind the quotation
to an identifier while coercing its type and then splicing the quotation,
e.g.
{{{
:set -fdefer-type-errors
:set -XTemplateHaskell
import Language.Haskell.TH
let x = [d|a = ()|] :: Q Exp
:t $x
}}}
The patch also makes GHC too aggressive than it should be with respect to
type errors within declaration quotations. For example the type error in
`$([d|a = () ()|])` could be deferred but after this patch it becomes an
eager type error. Likewise, you can no longer do e.g. `:t $([|() ()|])`
within GHCi to view the type of a malformed expression quotation.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7276#comment:5
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] #7294: -fdefer-type-errors doesn't produce a warning
#7294: -fdefer-type-errors doesn't produce a warning --+- Reporter: Feuerbach| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) |Version: 7.6.1 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Difficulty: Unknown Testcase: gadt/T7293, T7294| Blockedby: Blocking: |Related: --+- Comment(by simonmar): Ok... was there a patch to merge, or did this get fixed as a side effect of other things? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7294#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] #7294: -fdefer-type-errors doesn't produce a warning
#7294: -fdefer-type-errors doesn't produce a warning
--+-
Reporter: Feuerbach| Owner:
Type: bug | Status: merge
Priority: normal | Milestone:
Component: Compiler (Type checker) |Version: 7.6.1
Resolution: fixed| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: GHC accepts invalid program | Difficulty: Unknown
Testcase: gadt/T7293, T7294| Blockedby:
Blocking: |Related:
--+-
Changes (by simonpj):
* status: closed = merge
Comment:
Harump. I'd forgotten that the branch has `-fdefer-type-errors` too. I
think that the relevant patch is this one
{{{
commit 629d1f48b513be3cc662ea79376737dbcdb6b18f
Author: Simon Peyton Jones simo...@microsoft.com
Date: Thu Oct 4 17:54:38 2012 +0100
Improve erorr location for Given errors
Note [Inaccessible code].
Fixes Trac #7293.
compiler/typecheck/TcErrors.lhs | 91
+++---
compiler/typecheck/TcRnTypes.lhs |5 ++-
2 files changed, 59 insertions(+), 37 deletions(-)
}}}
It may require a little adjustment to account for the fact that the branch
does not have holes. I'm not sure it's worth much effort, but perhaps
worth a go.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7294#comment:8
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] #7294: -fdefer-type-errors doesn't produce a warning
#7294: -fdefer-type-errors doesn't produce a warning --+- Reporter: Feuerbach| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) |Version: 7.6.1 Resolution: duplicate| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = duplicate Comment: Yes, I'm afraid #3927 is the offending ticket. Overlapping patterns are figured out *after* type checking, because it involves a sort of global analysis of the block of patterns. Fixing overlapping-pattern warnings in the presence of GADTs requires some careful thought; a nice self-contained project. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7294#comment:4 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] #7294: -fdefer-type-errors doesn't produce a warning
#7294: -fdefer-type-errors doesn't produce a warning --+- Reporter: Feuerbach| Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) |Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by simonmar): * status: closed = new * resolution: duplicate = Comment: The second problem mentioned is #3927, but the first problem is still unresolved, right? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7294#comment:5 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] #7294: -fdefer-type-errors doesn't produce a warning
#7294: -fdefer-type-errors doesn't produce a warning --+- Reporter: Feuerbach| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) |Version: 7.6.1 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Difficulty: Unknown Testcase: gadt/T7293, T7294| Blockedby: Blocking: |Related: --+- Changes (by simonpj): * status: new = closed * testcase: = gadt/T7293, T7294 * resolution: = fixed Comment: No, it's fine now. Without `-fdefer-type-errors` we get an error (test `gadt/T7293`); with `-fdefer-type-errors` we get a warning (test `gadt/T7294`). Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7294#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] #7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault
#7276: -fdefer-type-errors allows the types of quotations to be coerced, causing
segmentation fault
+---
Reporter: parcs | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple| Architecture: Unknown/Multiple
Failure: Compile-time crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
Comment(by simonpj@…):
commit a501c950652d3cb56335781289f0f502c0cf2f4e
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Mon Oct 1 21:52:19 2012 +0100
Make sure that we check for type errors strictly in a Template Haskell
splice, even if -fdefer-type-errors is on
We're going to run this code, so there's no point in deferring type
errors. Worse, TcSplice uses unsafeCoerce (for vevy good reasons),
so splicing a type into a place where an expression is expected would
yield a seg-fault if we plough on regardless.
Fixes Trac #7276
compiler/typecheck/TcSplice.lhs |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7276#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] #7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault
#7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault -+-- Reporter: parcs | Owner: Type: bug | Status: merge Priority: normal| Milestone: Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown |Testcase: th/T7276 Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * status: new = merge * difficulty: = Unknown * testcase: = th/T7276 Comment: Excellent point, thank you. Worth merging this to 7.6 branch Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7276#comment:4 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] #7294: -fdefer-type-errors doesn't produce a warning
#7294: -fdefer-type-errors doesn't produce a warning
-+--
Reporter: Feuerbach| Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.6.1| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: GHC accepts invalid program | Testcase:
Blockedby: | Blocking:
Related: |
-+--
With the attached code I get the expected error
{{{
sing.hs:20:8:
Couldn't match type 'False with 'True
Inaccessible code in
the type signature for
nth :: (k : n) ~ 'True = Vec a n - SNat k - a
}}}
However, if I compile with -fdefer-type-errors, compilation goes clean
without any errors or warnings.
Also, if I comment out the last line (with inaccessible code) and compile
with -fforce-recomp -fwarn-incomplete-patterns, then I get a false warning
{{{
sing.hs:21:1: Warning:
Pattern match(es) are non-exhaustive
In an equation for `nth': Patterns not matched: Nil _
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7294
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] #7294: -fdefer-type-errors doesn't produce a warning
#7294: -fdefer-type-errors doesn't produce a warning -+-- Reporter: Feuerbach| Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Testcase: Blockedby: | Blocking: Related: | -+-- Comment(by Feuerbach): In fact, the false warning is produced regardless of -fdefer-type-errors. Is it a known limitation, or should I open a separate ticket for it? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7294#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] #7294: -fdefer-type-errors doesn't produce a warning
#7294: -fdefer-type-errors doesn't produce a warning -+-- Reporter: Feuerbach| Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.1| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Testcase: Blockedby: | Blocking: Related: | -+-- Changes (by Feuerbach): * component: Compiler = Compiler (Type checker) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7294#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] #7294: -fdefer-type-errors doesn't produce a warning
#7294: -fdefer-type-errors doesn't produce a warning -+-- Reporter: Feuerbach| Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.1| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Testcase: Blockedby: | Blocking: Related: | -+-- Changes (by goldfire): * cc: eir@… (added) Comment: The second problem you mention (about the spurious warning of an incomplete pattern) is already known. See #3927. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7294#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] #7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault
#7276: -fdefer-type-errors allows the types of quotations to be coerced, causing
segmentation fault
+---
Reporter: parcs | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple| Architecture: Unknown/Multiple
Failure: Compile-time crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
`-fdefer-type-errors` allows the type of a quotation to be coerced into
another quotation type. This allows e.g. a declaration quotation to be
used in a place where an expression quotation is expected, which results
in a compile-time segmentation fault.
The following GHCi script demonstrates the issue:
{{{
:set -fdefer-type-errors
:set -XTemplateHaskell
$([d|a = ()|])
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7276
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] #7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault
#7276: -fdefer-type-errors allows the types of quotations to be coerced, causing
segmentation fault
+---
Reporter: parcs | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.6.1 | Keywords:
Os: Unknown/Multiple| Architecture: Unknown/Multiple
Failure: Compile-time crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
Comment(by guest):
Just a note: since defering for expressions is off in GHCi by default, the
error can be reproduced with
{{{
let x = $([d|a = ()|])
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7276#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] #7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault
#7276: -fdefer-type-errors allows the types of quotations to be coerced, causing segmentation fault +--- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: Compile-time crash | Testcase: Blockedby: | Blocking: Related: | +--- Comment(by parcs): Oh right, thanks. I meant to say `:t $([d|a = ()|])` -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7276#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
[Haskell-cafe] parsing ghc type errors
Dear Haskell-cafe,
When dealing with ghc type errors I often see messages like
Couldn't match expected type `ghc-prim:GHC.Types.IO{tc 32I}
MyTypeNameHere{tc r1d8}'
with actual type `ghc-prim:GHC.Types.IO{tc 32I}
MyOtherTypeNameHere{tc r1d8}'
Could you please help me understand the meaning of the entities
in {} and why are they useful, or point to a source of information about them?
Messages where familiar types are referenced are easy to read,
but occasionally I get messages of the sort
with actual type `[( b0{tv t3p} [tau] :: ghc-prim:GHC.Prim.*{(w) tc
34d} )]'
How do I go about reading the type
[( b0{tv t3p} [tau] :: ghc-prim:GHC.Prim.*{(w) tc 34d} )]
?
E.g., where the names 'b0' and '[tau]' come from?
What does '(w)' in '{(w) tc 34d}' mean?
Thank you,
Semen
--
Семен Тригубенко
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [GHC] #7023: Panic when compiling with -fdefer-type-errors
#7023: Panic when compiling with -fdefer-type-errors
-+--
Reporter: guest | Owner: simonpj
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 7.5
Keywords:| Os: MacOS X
Architecture: Unknown/Multiple | Failure: Compile-time crash
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by simonpj@…):
commit c1f01e351759e7c25818b05e32bdb7b702dac6f2
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Sat Jul 14 13:18:34 2012 +0100
Do not discard insoluble constraints in simplifyInfer
Before -fdefer-type-errors there we no insolubles
(because we'd have failed before then), but with -fdefer-type-errors
there can be. The code is acutally a bit simpler: we just call
emitConstraints, and eliminate the bogus-looking emitWC from
TcRnMonad.
There's a bit more tidying up to do, concerning the places we use
keepWanted, but I need to talk to Dimitrios about that.
Meanwhile this fixes Trac #7023
compiler/typecheck/TcRnMonad.lhs |5 -
compiler/typecheck/TcSimplify.lhs |7 ---
2 files changed, 4 insertions(+), 8 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7023#comment:4
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] #7023: Panic when compiling with -fdefer-type-errors
#7023: Panic when compiling with -fdefer-type-errors -+-- Reporter: guest | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 7.5 Resolution: fixed | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: typecheck/should_run/T7023 | Blockedby: Blocking: |Related: -+-- Changes (by simonpj): * status: new = closed * testcase: = typecheck/should_run/T7023 * resolution: = fixed Comment: Thanks! The above patch fixes it. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7023#comment:5 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] #7023: Panic when compiling with -fdefer-type-errors
#7023: Panic when compiling with -fdefer-type-errors
+---
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.5 | Keywords:
Os: MacOS X | Architecture: Unknown/Multiple
Failure: Compile-time crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
Changes (by dreixel):
* architecture: x86_64 (amd64) = Unknown/Multiple
Comment:
I can confirm this. Compilation fails with:
{{{
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.5 for i386-unknown-linux):
cgLookupPanic (probably invalid Core; try -dcore-lint)
cobox{v ahw} [lid]
static binds for:
local binds for:
}}}
`-dcore-lint` gives us:
{{{
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
*** Core Lint errors : in result of Desugar (after optimization) ***
no location info: Warning:
In the expression: GHC.Types.:
@ [GHC.Types.Char]
(case cobox_ahw of _ { GHC.Types.Eq# cobox_dir -
(GHC.Types.I# 1)
`cast` (cobox_dir :: GHC.Types.Int ~#
[GHC.Types.Char])
})
(GHC.Types.[] @ [GHC.Types.Char])
cobox_ahw :: GHC.Types.Int ~ [GHC.Types.Char]
[LclId] is out of scope
*** Offending Program ***
Rec {
Main.a :: [[GHC.Types.Char]]
[LclIdX]
Main.a =
GHC.Types.:
@ [GHC.Types.Char]
(GHC.Types.:
@ GHC.Types.Char
(GHC.Types.C# 'x')
(GHC.Types.[] @ GHC.Types.Char))
(GHC.Types.:
@ [GHC.Types.Char]
(case cobox_ahw of _ { GHC.Types.Eq# cobox_dir -
(GHC.Types.I# 1)
`cast` (cobox_dir :: GHC.Types.Int ~# [GHC.Types.Char])
})
(GHC.Types.[] @ [GHC.Types.Char]))
Main.main :: GHC.Types.IO ()
[LclIdX]
Main.main =
System.IO.putStrLn (GHC.CString.unpackCString# Hello World)
:Main.main :: GHC.Types.IO ()
[LclIdX]
:Main.main = GHC.TopHandler.runMainIO @ () Main.main
end Rec }
*** End of Offense ***
no location info:
Compilation had errors
}}}
I'm not entirely sure what's going on, though. Why did `cobox_ahw` not get
replaced by its evidence (a runtime error)?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7023#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] #7023: Panic when compiling with -fdefer-type-errors
#7023: Panic when compiling with -fdefer-type-errors -+-- Reporter: guest | Owner: simonpj Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.5 Keywords:| Os: MacOS X Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = simonpj * difficulty: = Unknown Comment: I'll investigate. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7023#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] #7023: Panic when compiling with -fdefer-type-errors
#7023: Panic when compiling with -fdefer-type-errors +--- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.5 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Compile-time crash | Testcase: Blockedby: | Blocking: Related: | +--- Running 7.5.20120621 Compiling attached program causes panic. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7023 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] #7023: Panic when compiling with -fdefer-type-errors
#7023: Panic when compiling with -fdefer-type-errors +--- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.5 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Compile-time crash | Testcase: Blockedby: | Blocking: Related: | +--- Comment(by guest): Sorry about the guest posting, signup seems to be down (just time'd out) I'll CC myself when I can get an account. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7023#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] #6162: defer-type-errors + unsafeCoerce
#6162: defer-type-errors + unsafeCoerce --+- Reporter: guest | Owner: Type: feature request| Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Keywords: defer-type-errors | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by simonpj): * difficulty: = Unknown Comment: But under unfavourable conditions you get a segmentation fault! The whole point of `-fdefer-type-errors` is that you get the same guarantees about lack of seg-faults and memory safety for type in-correct programs that you get for type-correct cones. As [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/ the paper] discusses. So I don't propose to change this. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6162#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] #6162: defer-type-errors + unsafeCoerce
#6162: defer-type-errors + unsafeCoerce --+- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal| Component: Compiler Version: 7.5 | Keywords: defer-type-errors Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- When evidence of `a ~ b` is missing, -fdefer-type-errors uses `error` to coerce `a` to `b`. It would nice to allow to use `unsafeCoerce` instead; for example `' ' :: Int` would give under favourable conditions `32`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6162 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] #5917: Don't defer type errors when evaluating a GHCi expression
#5917: Don't defer type errors when evaluating a GHCi expression
---+
Reporter: parcs | Owner:
Type: feature request | Status: closed
Priority: normal| Milestone:
Component: GHCi |Version: 7.5
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by simonpj):
* status: new = closed
* difficulty: = Unknown
* resolution: = fixed
Comment:
Good idea thanks
{{{
commit 301a718b8f9dd50d91bd03bbd2c3efa28ad203fd
Author: Patrick Palka patr...@parcs.ath.cx
Date: Tue Mar 6 19:27:40 2012 -0500
Don't defer type errors when evaluating a GHCi expression
It is unhelpful here because the expression will get evaluated right
away anyway, thus emitting a redundant warning followed by an
equivalent
runtime exception. If the expression were an ill-typed pure
expression,
_three_ equivalent type errors would get emitted (due to the two-phase
typechecking done in 'Plan C')
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5917#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] #5917: Don't defer type errors when evaluating a GHCi expression
#5917: Don't defer type errors when evaluating a GHCi expression --+- Reporter: parcs | Owner: Type: feature request | Status: new Priority: normal| Component: GHCi Version: 7.5 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- Hi, I have attached a patch that alters the behavior of GHCi to not defer type errors when evaluating an expression. My rationale is given within the patch. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5917 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] #5791: Defer other kinds of errors until runtime, not just type errors
#5791: Defer other kinds of errors until runtime, not just type errors -+-- Reporter: simonmar | Owner: Type: task | 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: Blockedby:|Blocking: Related: 5778 | -+-- In #5778 we added `-fdefer-type-errors` to turn type errors into warnings. We can do this for other kinds of errors too, notably out-of-scope errors, and there are plenty more errors that can be deferred by replacing the erroneous subexpression by a call to `error`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5791 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] #5791: Defer other kinds of errors until runtime, not just type errors
#5791: Defer other kinds of errors until runtime, not just type errors -+-- Reporter: simonmar | Owner: Type: task | 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: Blockedby:|Blocking: Related: 5778 | -+-- Description changed by simonmar: Old description: In #5778 we added `-fdefer-type-errors` to turn type errors into warnings. We can do this for other kinds of errors too, notably out-of- scope errors, and there are plenty more errors that can be deferred by replacing the erroneous subexpression by a call to `error`. New description: In #5624 we added `-fdefer-type-errors` to turn type errors into warnings. We can do this for other kinds of errors too, notably out-of-scope errors, and there are plenty more errors that can be deferred by replacing the erroneous subexpression by a call to `error`. -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5791#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
[Haskell-cafe] Re: Type errors, would extensions help?
Mauricio wrote: After you pointed my dumb mistake, I was able to build the first example -- without any of the extensions! Haskell can be misterious some times. Strange enough, I can't get the original (and, to my eyes, equal) problem to work. Indeed Haskell can be misterious sometimes. Now that you fixed the typo the first example compiles, but I think you will be surprised with its output: 1 % 5 5 % 1 As you can see, the type of printNumber is still monomorphic for the reasons explained by Ryan Ingram and Lennart Augustsson. It's only the peculiarity of the numeric classes in Haskell that makes two your examples different - the constant `5.0' has type `(Fractional t) = t', and (Ratio a) is an instance of Fractional. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type errors, would extensions help?
Hi,
I have this problem trying to define a function
inside a do expression. I tried this small code
to help me check. This works well:
---
import Data.Ratio ;
main = do {
printNumber - let {
print :: (Num n,Show n) = n - IO () ;
print n = do { putStrLn $ show n}
} in return print ;
print (1%5) ;
print 5.0
}
---
However, just removing 'Num n' gives:
Ambiguous type variable `n' in the constraint:
`Show n' arising from a use of `print' at teste.hs:7:16-20
Why is it ambiguous? Since I don't use numeric
functions, 'Num n,Show n' doesn't seem more specific.
Besides that, the real problem I have is a similar
function declared inside a 'let' as
col :: (WidgetClass w) = w-IO Int
col wid = do {...
that, after beeing used with w beeing Table (and
instance WidgetClass Table do exist) refuses beeing
used with DrawingArea (also with instance WidgetClass
DrawingArea), but I wasn't able to simulate that
in a small program, and don't know if it's related
to the case I'm showing.
Thanks for your kindness,
Maurício
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type errors, would extensions help?
Mauricio wrote:
Hi,
I have this problem trying to define a function
inside a do expression. I tried this small code
to help me check. This works well:
---
import Data.Ratio ;
main = do {
printNumber - let {
print :: (Num n,Show n) = n - IO () ;
print n = do { putStrLn $ show n}
} in return print ;
print (1%5) ;
print 5.0
}
---
I guess you intended to call printNumber in the quoted snippet?
There's a way to use GHC's extensions to do what you want, let me
illustrate with simpler example:
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ImpredicativeTypes #-}
t1 () = do f - (return id :: IO (forall a. a-a))
return (f foo, f True)
However, I would call this style unnatural and unnecessary. What's wrong
with plain 'let' or 'where' that work without any extensions?
t2 () = do let f = id
return (f foo, f True)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type errors, would extensions help?
I suggest you start using let in your do blocks; both of these
problems are solvable with let.
Binding with - instead of let makes the type system work harder,
and will generally require type annotations extensions for
polymorphic results. And it's almost never what you want, anyways;
you don't often have an object of type IO (forall a. a - a)
instead of forall a. IO (a - a) and this situation usually means
you should be using let instead.
Here's the Gtk example; the let on mkNotebook is not strictly
necessary but is just showing the concept in more places; I tend to
avoid x - do ... in my code; I feel it means I should be abstracting
more.
main = do
initGUI
j1 - drawingAreaNew
j2 - tableNew 1 1 True
let mkNotebook = do
note - notebookNew
let insertInNoteBook wid texto = do
lb - labelNew Nothing
labelSetMarkup lb texto
notebookAppendPageMenu note wid lb lb
insertInNotebook j1 J1
insertInNotebook j2 J2
return note
notebook - mkNotebook
putStrLn Finish
Also, is there a reason you hate the layout rule and are using
explicit semicolons everywhere?
-- ryan
On Thu, Jan 15, 2009 at 10:46 AM, Mauricio briqueabra...@yahoo.com wrote:
I have this problem trying to define a function
inside a do expression. I tried this small code
to help me check. This works well:
I guess you intended to call printNumber in the quoted snippet?
(...)
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ImpredicativeTypes #-}
After you pointed my dumb mistake, I was able to build
the first example -- without any of the extensions! Haskell
can be misterious some times.
Strange enough, I can't get the original (and, to my eyes,
equal) problem to work. This is the smallest I could get it
to be:
--- WARNING: wrong use of gtk, just to get an example
---
import Graphics.UI.Gtk ;
main = do {
initGUI ;
j1 - drawingAreaNew ; j2 - tableNew 1 1 True ;
notebook - do {
note - notebookNew ;
insertInNotebook - let {
colocar :: (WidgetClass w) = w - String - IO Int ;
colocar wid texto = do {
lb - labelNew Nothing ;
labelSetMarkup lb texto ;
notebookAppendPageMenu note wid lb lb
} } in return $ colocar ;
insertInNotebook j1 J1 ;
insertInNotebook j2 J2 ;
return note
} ;
putStrLn Finish
}
---
GHC says:
teste.hs:15:21:
Couldn't match expected type `DrawingArea'
against inferred type `Table'
In the first argument of `insertInNotebook', namely `j2'
In a stmt of a 'do' expression: insertInNotebook j2 J2
(...)
but I would like first argument of insert... to be any
instance of WidgetClass, be it Drawing... or Table.
Thanks,
Maurício
___
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
[Haskell-cafe] Re: Type errors, would extensions help?
I have this problem trying to define a function
inside a do expression. I tried this small code
to help me check. This works well:
I guess you intended to call printNumber in the quoted snippet?
(...)
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ImpredicativeTypes #-}
After you pointed my dumb mistake, I was able to build
the first example -- without any of the extensions! Haskell
can be misterious some times.
Strange enough, I can't get the original (and, to my eyes,
equal) problem to work. This is the smallest I could get it
to be:
--- WARNING: wrong use of gtk, just to get an example
---
import Graphics.UI.Gtk ;
main = do {
initGUI ;
j1 - drawingAreaNew ; j2 - tableNew 1 1 True ;
notebook - do {
note - notebookNew ;
insertInNotebook - let {
colocar :: (WidgetClass w) = w - String - IO Int ;
colocar wid texto = do {
lb - labelNew Nothing ;
labelSetMarkup lb texto ;
notebookAppendPageMenu note wid lb lb
} } in return $ colocar ;
insertInNotebook j1 J1 ;
insertInNotebook j2 J2 ;
return note
} ;
putStrLn Finish
}
---
GHC says:
teste.hs:15:21:
Couldn't match expected type `DrawingArea'
against inferred type `Table'
In the first argument of `insertInNotebook', namely `j2'
In a stmt of a 'do' expression: insertInNotebook j2 J2
(...)
but I would like first argument of insert... to be any
instance of WidgetClass, be it Drawing... or Table.
Thanks,
Maurício
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type errors, would extensions help?
Thanks, everything works now. What should I read to better understand the difference for the type system between using - and 'let'? That is not intuitive for me. About layout, I used to filter my code to better fit everyone taste before posting to this list. The filter stoped working due to some problems in 'Language.Haskell', but I'll rewrite it with haskell-src-exts before posting again. Thanks, Maurício I suggest you start using let in your do blocks; both of these problems are solvable with let. Binding with - instead of let makes the type system work harder, and will generally require type annotations extensions for polymorphic results. (...) Also, is there a reason you hate the layout rule and are using explicit semicolons everywhere? I have this problem trying to define a function inside a do expression. (...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type errors, would extensions help?
The - binding is lambda binding (look at how it desugars). Lambda bindings are monomorphic without any type extensions. The monadic 'let' binding is like regular 'let', so it's a point where the type checker does generalization, and so you get (possibly) polymorphic bindings from let. -- Lennart On Thu, Jan 15, 2009 at 11:20 PM, Mauricio briqueabra...@yahoo.com wrote: Thanks, everything works now. What should I read to better understand the difference for the type system between using - and 'let'? That is not intuitive for me. About layout, I used to filter my code to better fit everyone taste before posting to this list. The filter stoped working due to some problems in 'Language.Haskell', but I'll rewrite it with haskell-src-exts before posting again. Thanks, Maurício I suggest you start using let in your do blocks; both of these problems are solvable with let. Binding with - instead of let makes the type system work harder, and will generally require type annotations extensions for polymorphic results. (...) Also, is there a reason you hate the layout rule and are using explicit semicolons everywhere? I have this problem trying to define a function inside a do expression. (...) ___ 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
Re: [Haskell-cafe] Re: Type errors, would extensions help?
Here's the desugaring:
do { pattern - expression ; rest }
desugars to
expression = \temp - case temp of
pattern - do { rest }
_ - fail Pattern match failure
(where temp is a fresh variable not used elsewhere, and the failure
message usually includes source position)
Whereas
do { let pattern = expression ; rest }
desugars to
let pattern = expression in do { rest }
-- ryan
On Thu, Jan 15, 2009 at 3:26 PM, Lennart Augustsson
lenn...@augustsson.net wrote:
The - binding is lambda binding (look at how it desugars). Lambda
bindings are monomorphic without any type extensions. The monadic
'let' binding is like regular 'let', so it's a point where the type
checker does generalization, and so you get (possibly) polymorphic
bindings from let.
-- Lennart
On Thu, Jan 15, 2009 at 11:20 PM, Mauricio briqueabra...@yahoo.com wrote:
Thanks, everything works now.
What should I read to better understand the difference
for the type system between using - and 'let'? That is
not intuitive for me.
About layout, I used to filter my code to better fit
everyone taste before posting to this list. The filter
stoped working due to some problems in 'Language.Haskell',
but I'll rewrite it with haskell-src-exts before
posting again.
Thanks,
Maurício
I suggest you start using let in your do blocks; both of these
problems are solvable with let.
Binding with - instead of let makes the type system work harder,
and will generally require type annotations extensions for
polymorphic results. (...)
Also, is there a reason you hate the layout rule and are using
explicit semicolons everywhere?
I have this problem trying to define a function
inside a do expression. (...)
___
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [GHC] #1465: Type errors due to different package versions are a bit cryptic
#1465: Type errors due to different package versions are a bit cryptic
+---
Reporter: guest|Owner:
Type: bug | Status: closed
Priority: normal |Milestone: 6.8
Component: Compiler (Type checker) | Version: 6.6.1
Severity: normal | Resolution: fixed
Keywords: | Difficulty: Moderate (1 day)
Os: Unknown | Testcase: tcfail182, bug1465,
mod180
Architecture: Unknown |
+---
Changes (by simonmar):
* difficulty: Easy (1 hr) = Moderate (1 day)
* resolution: = fixed
* testcase: tcfail182 = tcfail182, bug1465, mod180
* status: new = closed
Comment:
Fixed:
{{{
Thu Sep 6 10:37:44 BST 2007 Simon Marlow [EMAIL PROTECTED]
* FIX #1465, error messages could sometimes say things like A.T doesn't
match A.T
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1465
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] #1465: Type errors due to different package versions are a bit cryptic
#1465: Type errors due to different package versions are a bit cryptic +--- Reporter: guest|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: tcfail182 Architecture: Unknown | +--- Comment (by simonmar): Trouble is, that's just the problem 'guest' reported. It's not enough to say that Display imported from M does not match Display imported from Y! We want to say where Display originally came from. What distinguishes these two types is the ''package'' they came from, not the defining module. In the original example, the defining modules were the same. GHC should never report the defining module of a name, because that breaks abstraction, and it isn't useful: the defining module might be unexposed, and undocumented. (I think we already report original names when the name in question is not in scope at all, perhaps this should be fixed too). I suggest that when the unqualified names of the types that failed to unify are the same, we report the package names, since this is the case that is likely to be confusing to the user. It's probably useful to report where the types were imported from too. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1465 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] #1465: Type errors due to different package versions are a bit cryptic
#1465: Type errors due to different package versions are a bit cryptic +--- Reporter: guest|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: tcfail182 Architecture: Unknown | +--- Comment (by simonpj): I've arranged (I believe already committed) that we report the package names UNLESS two type constructors with the same occurrence name come from the same package -- and only then report the module name. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1465 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] #1465: Type errors due to different package versions are a bit cryptic
#1465: Type errors due to different package versions are a bit cryptic +--- Reporter: guest|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: tcfail182 Architecture: Unknown | +--- Comment (by Isaac Dupree): Reporting the originating package may prove more difficult/abstraction- breaking once packages can re-export types from other packages (the same way we have difficulty with modules that re-export the types from other modules) -- just a note for future reference, perhaps. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1465 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] #1465: Type errors due to different package versions are a bit cryptic
#1465: Type errors due to different package versions are a bit cryptic
+---
Reporter: guest|Owner:
Type: bug | Status: new
Priority: normal |Milestone: 6.8
Component: Compiler (Type checker) | Version: 6.6.1
Severity: normal | Resolution:
Keywords: | Difficulty: Easy (1 hr)
Os: Unknown | Testcase: tcfail182
Architecture: Unknown |
+---
Changes (by simonpj):
* testcase: = tcfail182
Comment:
Excellent suggestion. I've arranged to print more info if the two types
have the same occurrence name, since some confusion may then occur. For
example:
{{{
module Foo where
import qualified Prelude
import Prelude hiding( Maybe )
data Maybe a = Foo
f :: Prelude.Maybe a - Int
f Foo = 3
}}}
now produces the error:
{{{
Foo.hs:11:2:
Couldn't match expected type `Prelude.Maybe a'
against inferred type `Maybe a1'
`Prelude.Maybe' is defined in module `Data.Maybe' from package
`base'
`Maybe' is defined in this module
In the pattern: Foo
In the definition of `f': f Foo = 3
}}}
Can you check that your use-case is also improved, and if so close the
bug?
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1465
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] #1465: Type errors due to different package versions are a bit cryptic
#1465: Type errors due to different package versions are a bit cryptic +--- Reporter: guest|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: tcfail182 Architecture: Unknown | +--- Comment (by simonmar): I'm not sure about the defined in module bit. Won't this give rise to things like Int is defined in module GHC.Base, which could confuse the average user who doesn't have a clue what `GHC.Base` is, and finds that it isn't even documented? We should say where the module is imported from, not defined. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1465 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] #1465: Type errors due to different package versions are a bit cryptic
#1465: Type errors due to different package versions are a bit cryptic +--- Reporter: guest|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: tcfail182 Architecture: Unknown | +--- Comment (by simonpj): Trouble is, that's just the problem 'guest' reported. It's not enough to say that `Display` imported from `M` does not match `Display` imported from `Y`! We want to say where `Display` originally came from. We could readily suppress the module name if the package names are different though. That way we'd only show the defining modules if both names came from the same package. Would that be better? Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1465 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] #1465: Type errors due to different package versions are a bit cryptic
#1465: Type errors due to different package versions are a bit cryptic +--- Reporter: guest|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: tcfail182 Architecture: Unknown | +--- Comment (by Isaac Dupree): That sounds reasonable to me. Because, trouble is, type-identity in Haskell is ''defined'' by the identity of the defining module... although it would be just as accurate to say that the entire set of package×modules it's exported from define its identity (from the point of view of the type's user), and those could be listed or one of them chosen. Except ... a type's ''name'' doesn't necessarily even have to be exported anywhere for it to be causing type errors (admittedly a bad practice to be exporting things whose type signature cannot be written externally). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1465 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] #1465: Type errors due to different package versions are a bit cryptic
#1465: Type errors due to different package versions are a bit cryptic +--- Reporter: guest|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | +--- Changes (by simonmar): * milestone: = 6.8 * type: feature request = bug Comment: Yes, this is really a bug, so I'm marking it as such. We thought about it, and then promptly forgot about it, when we added support for multiple versions of packages, I don't think we want to ''always'' add the package name. What is a non- local type? One that comes from another package? Then `Int` is non- local too. My suggestion would be to add the package name if the types that fail to unify have the same qualified name. Perhaps add an option to include the package names unconditionally. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1465 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] #1465: Type errors due to different package versions are a bit cryptic
#1465: Type errors due to different package versions are a bit cryptic
--+-
Reporter: guest| Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler (Type checker) |Version: 6.6.1
Severity: normal | Keywords:
Difficulty: Easy (1 hr) | Os: Unknown
Testcase: | Architecture: Unknown
--+-
Users of xmonad who've compiled one dependent library against X11 1.2, and
then update X11, and attempt to recompile xmonad against the new X11
1.2.2, get a cryptic type error:
{{{
Couldn't match expected type `Graphics.X11.Xlib.Types.Display'
against inferred type `Display'
}}}
Perhaps non-local types should be printed with their package name and
version, which would clarify this error. Something like:
{{{
Couldn't match expected type `X11-1.2:
Graphics.X11.Xlib.Types.Display'
against inferred type `X11-1.2.2: Display'
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1465
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: Type errors in Haskell programming languages - Plz help
Hello. The code is as follows - -- Code starts -- entry :: [Char] - [(Char,Int)] entry list = do t - getGroups list mergeGroups t getGroups :: [Char] - [(Char,Int)] mergeGroups :: [(Char,Int)] - [(Char,Int)] -- Code Ends -- You probably mean: entry list = let t = getGroups list in mergeGroups t or simpler entry = mergeGroups . getGroups Take a look at the instance Monad [ ] in the Prelude to see, why your program does not work. Ciao, Steffen ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Type errors in Haskell programming languages - Plz help
Thanks Steffen. This one worked. Cheers Karthik. --- [EMAIL PROTECTED] wrote: Hello. The code is as follows - -- Code starts -- entry :: [Char] - [(Char,Int)] entry list = do t - getGroups list mergeGroups t getGroups :: [Char] - [(Char,Int)] mergeGroups :: [(Char,Int)] - [(Char,Int)] -- Code Ends -- You probably mean: entry list = let t = getGroups list in mergeGroups t or simpler entry = mergeGroups . getGroups Take a look at the instance Monad [ ] in the Prelude to see, why your program does not work. Ciao, Steffen ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: understanding type errors - was: Compiler error using IO
Bjorn Lisper wrote: ... Is there any work being done on intelligent error messages for higher-order implicitly typed languages? One could perhaps come up with search strategies that tries to find a minimal number of program transformations (edit distance) that yields a syntactically correct and well-typed program. For instance, in the case of type errors one could try to search for the minimal number of definitions that have to be removed to make the remaining program well-typed, and then report the removed definitions as likely sources of the errors. Has anyone done this? Quite a number of people have published work on helping the programmer to locate the source of type errors in Hindley-Milner typed languages. I presented a paper about this subject at last ICFP. Mainly my paper is about a way of viewing the types of arbitrary subexpressions of a program. Note that you can only attach a type to an expression such as f x if you know the types of f and x. However, f x may appear in the definition body of f. You don't want cyclic explanations of types... I propose to have the user either browse freely through the typings of arbitrary expressions, or use a method called algorithmic debugging to locate the source of a type error. The algorithmic debugger asks the user if certain typings for certain expressions are correct according to his/her intentions. After some yes/no answers the debugger gives the location of the error. Other people have developed methods for more intelligent error messages, although not exactly in the way you propose. Have a look at the Related Work Section of my paper. You can get it from my web page (URL below). I am a bit doubtful about the practical usefulness of intelligent error messages. It is easy to create examples where a program can be made type correct by one of many rather different small transformations, all of similar complexity. I believe such examples do occur in practise and hence knowledge of the intended semantics is necessary to locate errors. However, with all the many proposals for better error location, there is definitely a lack of practical evaluation. Basically for each proposed method there exists only a toy implementation for a toy language, each method for a different language (and most of these implementations don't even seem to be available). I want to extend my prototype, replacing the type inference phase of nhc98, but I haven't yet had the time... Ciao, Olaf -- OLAF CHITIL, Dept. of Computer Science, The University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: monad type errors in class definition?
class MetaData a where
constructorName::a-String
mapArgs::(MetaData b,MonadPlus c) = (b-c)-a-[c]
results in the error
Illegal type "[c]" in constructor application
If I replace MonadPlus with Show or Num there is no error.
(Replacing MonadPlus with Monad also result in an error)
What is so special about MonadPlus and Monad that they result in an error,
but Show or Num don't.
The problem is that MonadPlus expects a type constructor and Show
expects just a type.
As your variable c is not applied in the right hand side, it is
considered to be a variable for a type, and not for a type constructor.
You should say something as
mapArgs::(MetaData b,MonadPlus c) = (b-c a)-a-[c a]
or similar.
In the paper
Functional Programming with Overloading and Higher-Order Polymorphism,
Mark P. Jones, First International Spring School on Advanced Functional
Programming Techniques, B{\aa}stad, Sweden, Springer-Verlag Lecture
Notes in Computer Science 925, May 1995.
you can find a very good explanation of this stuff (about kinds, and
kind inference). It is available at
http://www.cs.nott.ac.uk/~mpj/springschool.html
Fidel.
Re: monad type errors in class definition?
I am trying to write some primitives to make it easy to manipulate haskell datatypes without knowing what they are. However the following class: class MetaData a where constructorName::a-String mapArgs::(MetaData b,MonadPlus c) = (b-c)-a-[c] results in the error Illegal type "[c]" in constructor application If I replace MonadPlus with Show or Num there is no error. (Replacing MonadPlus with Monad also result in an error) What is so special about MonadPlus and Monad that they result in an error, but Show or Num don't. Well nothing...except for the fact Monad and its cousins are higher order types. Consider our favorite instance of the Monad classes, i.e. good ol' lists. Substituting in the above type specification, we'd get a type of (b-[])-a-[[]] for mapArgs. What would that _mean_? (Curried applications of higher-order types cannot exist in isolation). HTH, --Artie Gold
Re: type errors
Ok, I did not reconize this solution, it seems to me the (nearly) proper one. But why not write: class = Dictionary dict where delete :: (Eq key, Ord key) = key - dict key dat - dict key dat ... So one could avoid multiparamter classes at all. The two types key and dat should be inferred by the type of dict (which is expressed by 'dict key dat'). I can't think about a dictionary where key or dat are not associated with dict. That's the usual approach taken with single parameter type classes. However, not every implementation for finite maps (the functional programmer's term for dictionary) works for all element types. Think of tries or general tries (see Okasaki's book `Purely functional data structures', p. 163-169). Or else we could have a different restriction on the element types, eg (Hashable key) instead of (Ord key) for hash based implementations. That said the following declarations seems appropriate (cf PFDS, p. 204): class FiniteMap map k where empty :: map k a insert :: k - a - map k a - map k a delete :: k - map k a - map k a instance (Ord k) = FiniteMap SplayTree k where instance (Hashable k) = FiniteMap HashTable k where Ad-hoc tries: instance FiniteMap Trie [k] where Tries where the mapping from edge labels to tries is parametrised: instance (FiniteMap m k) = FiniteMap (Trie m) [k] where Cheers, Ralf
Re: type errors
Actually I think you would be better off with a class like this: class (Eq key, Ord key) = Dictionary dict key where delete :: key - dict dat - dict dat search :: key - dict dat - (key, SearchResult dat, dict dat) searchList :: [key] - dict dat - ([(key,SearchResult dat)],dict dat) Ok, I did not reconize this solution, it seems to me the (nearly) proper one. But why not write: class = Dictionary dict where delete :: (Eq key, Ord key) = key - dict key dat - dict key dat ... So one could avoid multiparamter classes at all. The two types key and dat should be inferred by the type of dict (which is expressed by 'dict key dat'). I can't think about a dictionary where key or dat are not associated with dict. Yes, that's ok too. You might find my paper "Bulk types with class" somewhat relevant. http://www.dcs.gla.ac.uk/~simonpj/papers.html Simon
RE: type errors
| delete :: (Dictionary dict key dat) = key - dict - dict | | It would not *always* result in ambiguity. For example, consider | | instance Dictionary (MyDict dat) Int dat where ... | | f :: MyDict dat - MyDit dat | f d = delete (3::Int) d | | Here, the polymorphism in 'dat' doesn't affect which instance | is chosen. Even if you relaxed the restriction on ambiguously typed members in a class declaration, I don't think this definition of f would be accepted. The principal type of f ought to be: (Dictionary (MyDict dat) Int dat') = MyDict dat - MyDict dat Note that the third parameter is still `ambiguous' (in the sense that it doesn't appear in the type to the right of the = arrow). From a type inference perspective, dat' enters the scene when you instantiate the polymorphic type for delete with three new type variables. The fact that you have an instance declaration for a tantalizingly similar class constraint doesn't help, because we can only use it if we can force dat and dat' to be equal. And for that, you need a more powerful mechanism (improvement, for example) for resolving overloading that goes some way beyond current Haskell. All the best, Mark
Re: type errors
Simon PJ wrote: So, I now think that the existing rule (all class variables must appear in each class-operation type signature) is probably the right one, but on stylistic rather than technical grounds. I feel very uneasy about this style of argument - a language designed this way becomes cluttered with all kinds of ad-hoc restrictions. It's ok for some compilers to have a warning that this may not be a very useful thing to do. eg things like this Warning (Foo.hs, line 3) Exporting data constructor "Leaf" without exporting type constructor "Tree". But I think it's a mistake to say you just aren't allowed to do it. That said, Mark PJ then wrote: Even if you relaxed the restriction on ambiguously typed members in a class declaration, I don't think this definition of f would be accepted. [argument about principal types deleted] This seems like a good basis on which to make language design decisions: we don't allow X because it doesn't make sense or because it conflicts with some other feature of the language. Alastair
Re: type errors
| class (Eq key, Ord key) = Dictionary dict key dat where |delete :: key - dict - dict | ... | the first error: | | Class type variable `dat' does not appear in method signature | delete :: key - dict - dict | | Why does ghc expect that I use all of the type variables? | Obviously I only need | the key to remove an entry of a dictionary. | | You're right. The restriction is excessive. Thanks for pointing | this out. Probably we should only require that at least one | of the class variables is constrained. I don't see this. The fact is that, if any of the variables in the class header don't appear in the type of a method, then that method will always have an ambiguous type. In this case, that would be: delete :: (Dictionary dict key dat) = key - dict - dict It would not *always* result in ambiguity. For example, consider instance Dictionary (MyDict dat) Int dat where ... f :: MyDict dat - MyDit dat f d = delete (3::Int) d Here, the polymorphism in 'dat' doesn't affect which instance is chosen. However, on further reflection, I now think: in any case where ambiguity would not result the original class declaration should be re-formulated So, I now think that the existing rule (all class variables must appear in each class-operation type signature) is probably the right one, but on stylistic rather than technical grounds. I don't see how Simon's suggestion of replacing "all" with "at least one" could be made to work in general. Such an approach is however possible if you are working with multiple parameter classes where the variables in one parameter are determined directly by the parameters in another. For example, consider the following class: class Collection elem col where empty :: col add :: elem - col - col del :: elem - col - col enum :: col - [elem] By the argument above, one should expect empty to be rejected as having an ambiguous type: Collection elem col = col. However, we could also imagine modifying the definition of ambiguity to take account of the fact that, in practice, the value of elem would probably be uniquely determined by the value of col, and hence the context in which empty is used could still provide enough information to allow the overloading to be resolved. Indeed. Consider instance Collection a MyColl where empty = MyEmpty ... But this would be nearly useless, since we then know nothing about the type elem. So, again, nothing seems to be gained by relaxing the restriction (unlike what I said yesterday). Simon
Re: type errors
The ghc compiler complains about 2 type errors in the following code: data SearchResult a = Found a | Fail class (Eq key, Ord key) = Dictionary dict key dat where delete :: key - dict - dict search :: key - dict - (key,SearchResult dat,dict) searchList :: [key] - dict - ([(key,SearchResult dat)],dict) searchList [] d = ([],d) searchList (x:xs) d = let (sresults,d') = searchList xs d (x',sresult,d'') = search x d' new_sres = (x',sresult):sresults in (new_sres,d'') the first error: Class type variable `dat' does not appear in method signature delete :: key - dict - dict Why does ghc expect that I use all of the type variables? Obviously I only need the key to remove an entry of a dictionary. You're right. The restriction is excessive. Thanks for pointing this out. Probably we should only require that at least one of the class variables is constrained. Actually I think you would be better off with a class like this: class (Eq key, Ord key) = Dictionary dict key where delete :: key - dict dat - dict dat search :: key - dict dat - (key, SearchResult dat, dict dat) searchList :: [key] - dict dat - ([(key,SearchResult dat)],dict dat) That is, you don't need the 'dat' type variable the class at all. Ambiguous type variable(s) `key', `dict' in the constraint `Dictionary dict key a10v' arising from use of `searchList' at Dtest2.hs:11 In an equation for function `searchList': searchList (x : xs) d = let (sresults, d') = searchList xs d (x', sresult, d'') = search x d' new_sres = (x', (sresult)) : sresults in (new_sres, (d'')) In the definition for method `searchList' You don't say which version of the compiler you are using, but I think this a palpable bug in 3.01 that is fixed in 3.02. So you are right to be confused by it! Simon
Re: type errors
Ambiguous type variable(s) `key', `dict' in the constraint `Dictionary dict key a10v' arising from use of `searchList' at Dtest2.hs:11 In an equation for function `searchList': searchList (x : xs) d = let (sresults, d') = searchList xs d (x', sresult, d'') = search x d' new_sres = (x', (sresult)) : sresults in (new_sres, (d'')) In the definition for method `searchList' You don't say which version of the compiler you are using, but I think this a palpable bug in 3.01 that is fixed in 3.02. Sorry, but I'm using 3.02 of the binary distribution Martin Stein
Re: type errors
You're right. The restriction is excessive. Thanks for pointing this out. Probably we should only require that at least one of the class variables is constrained. Why even require this? (All x) = x - x uses the class `All' which restricts its argument not one whit. -- P
Re: type errors
The ghc compiler complains about 2 type errors in the following code: data SearchResult a = Found a | Fail class (Eq key, Ord key) = Dictionary dict key dat where delete :: key - dict - dict search :: key - dict - (key,SearchResult dat,dict) searchList :: [key] - dict - ([(key,SearchResult dat)],dict) searchList [] d = ([],d) searchList (x:xs) d = let (sresults,d') = searchList xs d (x',sresult,d'') = search x d' new_sres = (x',sresult):sresults in (new_sres,d'') the first error: Class type variable `dat' does not appear in method signature delete :: key - dict - dict Why does ghc expect that I use all of the type variables? Obviously I only need the key to remove an entry of a dictionary. You're right. The restriction is excessive. Thanks for pointing this out. Probably we should only require that at least one of the class variables is constrained. Actually I think you would be better off with a class like this: class (Eq key, Ord key) = Dictionary dict key where delete :: key - dict dat - dict dat search :: key - dict dat - (key, SearchResult dat, dict dat) searchList :: [key] - dict dat - ([(key,SearchResult dat)],dict dat) That is, you don't need the 'dat' type variable the class at all. Ambiguous type variable(s) `key', `dict' in the constraint `Dictionary dict key a10v' arising from use of `searchList' at Dtest2.hs:11 In an equation for function `searchList': searchList (x : xs) d = let (sresults, d') = searchList xs d (x', sresult, d'') = search x d' new_sres = (x', (sresult)) : sresults in (new_sres, (d'')) In the definition for method `searchList' You don't say which version of the compiler you are using, but I think this a palpable bug in 3.01 that is fixed in 3.02. So you are right to be confused by it! Simon
RE: type errors
| class (Eq key, Ord key) = Dictionary dict key dat where |delete :: key - dict - dict | ... | the first error: | | Class type variable `dat' does not appear in method signature | delete :: key - dict - dict | | Why does ghc expect that I use all of the type variables? | Obviously I only need | the key to remove an entry of a dictionary. | | You're right. The restriction is excessive. Thanks for pointing | this out. Probably we should only require that at least one | of the class variables is constrained. I don't see this. The fact is that, if any of the variables in the class header don't appear in the type of a method, then that method will always have an ambiguous type. In this case, that would be: delete :: (Dictionary dict key dat) = key - dict - dict Overloading is usually resolved by looking at the context in which an identifier is used (in other words, by looking at the types that a functions arguments and results are expected to have). The problem with this example is that there will never be any way for the type system to determine which value the type variable `dat' should take. Technically, this results in a loss of coherence (i.e., an undefined semantics) for any program involving the function delete. The type checker might as well flag the declaration of delete as an error, because you won't ever be able to use it without producing an error. The solution to such problems is usually to create a small hierarchy of classes (with different numbers of parameters) such as: class DictWithDelete key dict where delete :: key - dict - dict class DictWithDelete key dict = Dictionary key dict dat where add :: key - dat - dict - dict etc... However, in this case, using a constructor class as Simon suggested is almost certainly the best approach. I don't see how Simon's suggestion of replacing "all" with "at least one" could be made to work in general. Such an approach is however possible if you are working with multiple parameter classes where the variables in one parameter are determined directly by the parameters in another. For example, consider the following class: class Collection elem col where empty :: col add :: elem - col - col del :: elem - col - col enum :: col - [elem] By the argument above, one should expect empty to be rejected as having an ambiguous type: Collection elem col = col. However, we could also imagine modifying the definition of ambiguity to take account of the fact that, in practice, the value of elem would probably be uniquely determined by the value of col, and hence the context in which empty is used could still provide enough information to allow the overloading to be resolved. This is one of the key ideas behind Chen, Hudak and Odersky's proposal for parametric classes. The weaker notion of ambiguity here is just what the AV operator (in my own thesis) was about. Note that this would require a new extension to the syntax of class declarations; at the moment, there is no way to express any kind of dependency between the parameters of a class. (Nor are there mechanisms in the compilers to enforce them!) All the best, Mark
Re: type errors
Actually I think you would be better off with a class like this: class (Eq key, Ord key) = Dictionary dict key where delete :: key - dict dat - dict dat search :: key - dict dat - (key, SearchResult dat, dict dat) searchList :: [key] - dict dat - ([(key,SearchResult dat)],dict dat) Ok, I did not reconize this solution, it seems to me the (nearly) proper one. But why not write: class = Dictionary dict where delete :: (Eq key, Ord key) = key - dict key dat - dict key dat ... So one could avoid multiparamter classes at all. The two types key and dat should be inferred by the type of dict (which is expressed by 'dict key dat'). I can't think about a dictionary where key or dat are not associated with dict. Martin Stein
