[GHC] #11482: Turn -fdefer-typed-holes on by default
#11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9497, #11481 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From http://www.devalot.com/articles/2013/07/why-haskell.html: You can, however, return an `undefined` value which when evaluated will terminate the program. Haskell programmers use this to stub out parts of the program during development and they’re easy to detect during a production build.↩ That's terrible, they should be using typed holes! Hypothesis: because `ghc -fdefer-typed-holes Test.hs` is annoying to type, haskellers currently reach for `undefined` instead of typed holes (i.e. `_`), to mark the part of their code that isn't finished yet. Richard writes in ticket:9497#comment:2: I'm -1 on [enabling -fdefer-typed-holes by default]. It seems to invite the possibility that holes could make their way into released code. That's true, but the alternative is worse: developers keep using `undefined` instead of typed holes. Since ghc doesn't show any warnings for using `undefined` (#8064), we should make it as easy as possible to use typed holes, which does always show a warning (unless explicitly suppressed). Having to specify a command-line flag is too high a barrier (since `undefined` is so well known and easy to use) Proposal: * ghc turns `-fdefer-typed-holes` on by default. * build scripts specify `-fno-defer-typed-holes` to make sure no holes make it into releases. * we encourage everyone to use `_` instead of `undefined`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11482 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9497, #11481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by thomie: @@ -8,1 +8,3 @@ - That's terrible, they should be using typed holes! + That's terrible, they should be using + [https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/typed- + holes.html typed holes]! @@ -22,3 +24,3 @@ - use typed holes, which does always show a warning (unless explicitly - suppressed). Having to specify a command-line flag is too high a barrier - (since `undefined` is so well known and easy to use) + use typed holes, which does show a warning (unless explicitly suppressed + with `-fno-warn-typed-holes`). Having to specify a command-line flag is + too high a barrier (since `undefined` is so well known and easy to use) New description: From http://www.devalot.com/articles/2013/07/why-haskell.html: You can, however, return an `undefined` value which when evaluated will terminate the program. Haskell programmers use this to stub out parts of the program during development and they’re easy to detect during a production build.↩ That's terrible, they should be using [https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/typed- holes.html typed holes]! Hypothesis: because `ghc -fdefer-typed-holes Test.hs` is annoying to type, haskellers currently reach for `undefined` instead of typed holes (i.e. `_`), to mark the part of their code that isn't finished yet. Richard writes in ticket:9497#comment:2: I'm -1 on [enabling -fdefer-typed-holes by default]. It seems to invite the possibility that holes could make their way into released code. That's true, but the alternative is worse: developers keep using `undefined` instead of typed holes. Since ghc doesn't show any warnings for using `undefined` (#8064), we should make it as easy as possible to use typed holes, which does show a warning (unless explicitly suppressed with `-fno-warn-typed-holes`). Having to specify a command-line flag is too high a barrier (since `undefined` is so well known and easy to use) Proposal: * ghc turns `-fdefer-typed-holes` on by default. * build scripts specify `-fno-defer-typed-holes` to make sure no holes make it into releases. * we encourage everyone to use `_` instead of `undefined`. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11482#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9497, #11481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Incorrect warning at compile-time @@ -24,1 +24,1 @@ - use typed holes, which does show a warning (unless explicitly suppressed + use typed holes, which do show a warning (unless explicitly suppressed New description: From http://www.devalot.com/articles/2013/07/why-haskell.html: You can, however, return an `undefined` value which when evaluated will terminate the program. Haskell programmers use this to stub out parts of the program during development and they’re easy to detect during a production build.↩ That's terrible, they should be using [https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/typed- holes.html typed holes]! Hypothesis: because `ghc -fdefer-typed-holes Test.hs` is annoying to type, haskellers currently reach for `undefined` instead of typed holes (i.e. `_`), to mark the part of their code that isn't finished yet. Richard writes in ticket:9497#comment:2: I'm -1 on [enabling -fdefer-typed-holes by default]. It seems to invite the possibility that holes could make their way into released code. That's true, but the alternative is worse: developers keep using `undefined` instead of typed holes. Since ghc doesn't show any warnings for using `undefined` (#8064), we should make it as easy as possible to use typed holes, which do show a warning (unless explicitly suppressed with `-fno-warn-typed-holes`). Having to specify a command-line flag is too high a barrier (since `undefined` is so well known and easy to use) Proposal: * ghc turns `-fdefer-typed-holes` on by default. * build scripts specify `-fno-defer-typed-holes` to make sure no holes make it into releases. * we encourage everyone to use `_` instead of `undefined`. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11482#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9497, #11481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): You make a good point. What about this design alternative: * ghc turns `-fdefer-typed-holes` on by default * Cabal / stack use `-fno-defer-typed-holes` by default. * We encourage everyone to use `_` instead of `undefined`. * If the type of a typed hole is known (that is, "pushed in", in the sense of bidirectional type-checking) we emit a very short, one line warning instead of the longer one with types. Even better, we could common up all of these warnings into one that says where the holes are. This design depends somewhat on what standard workflows are. (I have no clue about standard workflows, as I'm quite non-standard.) Do people use cabal/stack right from the get-go when starting a project? Or do they prototype in GHCi a bit before making a build structure? If it's the latter, then the design above makes sense. If it's the former, not so much. I also think the last point would be a nice part of this. The idea is that if you say {{{#!hs frooble :: Bool frooble = _ -- not sure if we're froobling today }}} we don't need a long-form warning telling us that the hole has type `Bool`. A short warning saying `hole at (...)` is enough. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11482#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9497, #11481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): A different approach to the problem would be a TotalHaskell extension. The first and simple approach would be to warn about any use of `undefined` and `error`, and the second much more sophisticated approach would be to warn only about bottoms that can be reached plus a termination check. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11482#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9497, #11481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Another option would be to turn `-fdefer-typed-holes` on by default in GHCi only. I'm not sure about this though. I general I prefer GHCi and GHC to behave the same as much possible. Their difference with regard to the MonomorphismRestriction is annoying enough already.
Cabal / stack use -fno-defer-typed-holes by default.
Do you mean `cabal init` would add `ghc-options: -fno-defer-typed-holes` to the `*.cabal` file it creates? Or the default `.cabal/config` would get that entry? Or Cabal would always pass it to ghc? One workflow is to add library dependencies to a `.cabal` file, and then run `cabal repl`, which starts ghci. I like the suggestion of emitting a shorter warning for holes. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11482#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC