Turn -fdefer-typed-holes on by default

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:87391:

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 (closed)), 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.

mentioned in issue #8064 (closed)

changed weight to 5

added Tfeature request Trac import labels

changed the description

Trac metadata

Trac field	Value
TypeOfFailure	OtherFailure → IncorrectWarning

added error messages label

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

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.

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.

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.

added Pnormal label