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
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 (山本和彦)
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
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
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
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?
many thanks
Simon
| -----Original Message-----
| From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-
| bounces@haskell.org] On Behalf Of Richard Eisenberg
| Sent: 11 March 2013 13:28
| To: Kazu Yamamoto (山本和彦)
| Cc: glasgow-haskell-users@haskell.org
| Subject: 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 (山本和彦)
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
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
On Mon, Mar 11, 2013 at 9:33 PM, Isaac Dupree
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
participants (6)
-
Edward Z. Yang -
Gabriel Dos Reis -
Isaac Dupree -
Kazu Yamamoto -
Richard Eisenberg -
Simon Peyton-Jones