improve documentation of -fdefer-typed-holes for naked expressions in ghci

[int-e]

Consider the following ghci session.

GHCi, version 8.2.1: http://www.haskell.org/ghc/  :? for help
Prelude> :set -fdefer-typed-holes -Wno-typed-holes
Prelude> :set -fdefer-out-of-scope-variables -Wno-deferred-out-of-scope-variables
Prelude> let x = [_]; y = [r]
Prelude> (length x, length y)
(1,1)
Prelude> length [_]

<interactive>:4:9: error:
    • Found hole: _ :: a0
      Where: ‘a0’ is an ambiguous type variable
    • In the expression: _
      In the first argument of ‘length’, namely ‘[_]’
      In the expression: length [_]
    • Relevant bindings include it :: Int (bound at <interactive>:4:1)
Prelude> length [r]
1

Why does the length [_] expression produce a type error immediately instead of being deferred?

(I've asked the same question in #14367 but this looks like a real bug.)

The documentation can be improved here, see comment 2

[monoidal]

Does ​this answer your question?

[int-e]

Replying to monoidal:

Does ​this answer your question?

Yes and no. I still believe that the behavior is surprising, but this means it's a feature, not a bug (I don't care enough to argue otherwise). Btw, from this section I would conclude that length [r] should also produce an error, since both typed holes and out of scope variables fall under the headline ​Deferring type errors to runtime.

In any case it appears that the documentation can be improved a bit.

• clarify in ​Deferred type errors in GHCi that this applies to type checking errors (including typed holes) but not to name resolution (out of scope variables)
• I didn't find the GHCi exception when reading ​Typed Holes so a forward reference may be helpful
• The description of ​-fdefer-type-errors should mention that it implies -fdefer-out-of-scope-variables

[int-e]

#10249 and #11130 provide some rationale for the current behavior from ghc's side. See also ​https://phabricator.haskell.org/D1527

[sighingnow]

I think that the Opt_DeferOutOfScopeVariables isn't cancelled for naked expression in ghci should be a bug. Allowing length [r] is also unhelpful and may lead to some confusion for newcomers. I think this should be fixed as well.