headers
Kazu Yamamoto | 11 Mar 2013 08:45
Picon
Gravatar

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
Permalink | Reply |
headers
Richard Eisenberg | 11 Mar 2013 14:27
Favicon
Gravatar

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
(Continue reading)

Permalink | Reply |
headers
Kazu Yamamoto | 11 Mar 2013 14:47
Picon
Gravatar

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
Permalink | Reply |
headers
Kazu Yamamoto | 12 Mar 2013 02:57
Picon
Gravatar

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
Permalink | Reply |
headers
Simon Peyton-Jones | 12 Mar 2013 00:04
Picon
Favicon
Gravatar

RE: runghc -fdefer-type-errors

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 <at> haskell.org [mailto:glasgow-haskell-users-
|  bounces <at> haskell.org] On Behalf Of Richard Eisenberg
|  Sent: 11 March 2013 13:28
|  To: Kazu Yamamoto (山本和彦)
|  Cc: glasgow-haskell-users <at> 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
(Continue reading)

Permalink | Reply |
headers
Edward Z. Yang | 12 Mar 2013 00:08
Picon
Favicon

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
Permalink | Reply |
headers
Isaac Dupree | 12 Mar 2013 03:33

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
Permalink | Reply |
headers
Gabriel Dos Reis | 13 Mar 2013 00:25

Re: runghc -fdefer-type-errors

On Mon, Mar 11, 2013 at 9:33 PM, Isaac Dupree
<ml <at> 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.)
(Continue reading)

Permalink | Reply |

Gmane