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: 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: base package -- goals
On Mon, Mar 11, 2013 at 4:45 PM, Simon Peyton-Jones wrote: > B Better for internal implementation (eg using containers or bytestring in > base) > Note that this also means better code for external clients, as we can offer e.g. a better System.IO that lets people use Handles to read Text and ByteStrings in a more natural way (i.e. the I/O functions will be in one place, not spread out throughout N data structure libraries). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: base package -- goals
| I don’t feel in the position to actually make a call here, or even to cast a vote with | confidence, but I’m happy to continue summarizing the discussion until a | consensus is found. If there is more discussion, that is. I've updated the page http://hackage.haskell.org/trac/ghc/wiki/SplitBase a bit. It seems to me that there are two kinds of goals A Better for external clients (stable APRs, few version bumps) B Better for internal implementation (eg using containers or bytestring in base) On the Wiki page, (G1) and (G2) are to do with group (A). And this seems best handled by defining client-facing shim packages that export just what you want. However (G4) and later seem to be concerned with (B), and they clearly do require re-structuring the code. It seems entirely possible to me that BOTH will be needed. That is, the structure to achieve (B) will not be precisely what is wanted for (A). So it seems to be me that both approaches are valid and we might want to do both. We can do them in either order, or simultaneously. (Mind you, doing (A) first would make (B) less disruptive for our users.) In short, less of an either/or, more of a both/and. Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Joachim Breitner | Sent: 07 March 2013 20:22 | To: glasgow-haskell-users@haskell.org | Subject: Re: base package -- goals | | Hi, | | Am Dienstag, den 26.02.2013, 10:08 + schrieb Simon Peyton-Jones: | > I think it would be vv helpful to have all these goals articulated on | > the wiki page. | > | > http://hackage.haskell.org/trac/ghc/wiki/SplitBase | > | | well, all the goals are there (or are they not sufficiently well explained)? | | I also tried to compare the two approaches – the re-exporting API-specifying | packages and the actual split of base – by listing their advantages (I skipped the | disadvantages, these would just be the negation of the other advantages list...) at | http://hackage.haskell.org/trac/ghc/wiki/SplitBase#Approaches | | I don’t feel in the position to actually make a call here, or even to cast a vote with | confidence, but I’m happy to continue summarizing the discussion until a | consensus is found. If there is more discussion, that is.| | Greetings, | Joachim | | -- | Joachim "nomeata" Breitner | Debian Developer |nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C |JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata ___ 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
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-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@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 (山本和彦) 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
___
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
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 (山本和彦) 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
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
