runghc -fdefer-type-errors

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

runghc -fdefer-type-errors

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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: runghc -fdefer-type-errors

Richard Eisenberg-2
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 (山本和彦) <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: runghc -fdefer-type-errors

Kazu Yamamoto (山本和彦)
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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: runghc -fdefer-type-errors

Simon Peyton Jones
In reply to this post by Richard Eisenberg-2
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: [hidden email] [mailto:glasgow-haskell-users-
|  [hidden email]] On Behalf Of Richard Eisenberg
|  Sent: 11 March 2013 13:28
|  To: Kazu Yamamoto (山本和彦)
|  Cc: [hidden email]
|  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 (山本和彦) <[hidden email]> 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
|  > [hidden email]
|  > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|  
|  
|  _______________________________________________
|  Glasgow-haskell-users mailing list
|  [hidden email]
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: runghc -fdefer-type-errors

Edward Z. Yang
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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: runghc -fdefer-type-errors

Kazu Yamamoto (山本和彦)
In reply to this post by Kazu Yamamoto (山本和彦)
>> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: runghc -fdefer-type-errors

Isaac Dupree-3
In reply to this post by Simon Peyton Jones
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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: runghc -fdefer-type-errors

Gabriel Dos Reis
On Mon, Mar 11, 2013 at 9:33 PM, Isaac Dupree
<[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users