#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