Opened 2 years ago

Last modified 19 months ago

#14370 new task

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

Reported by: int-e Owned by:
Priority: normal Milestone:
Component: Documentation Version: 8.2.1
Keywords: DeferredErrors Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Incorrect error/warning at compile-time Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by int-e)

Consider the following ghci session.

GHCi, version 8.2.1:  :? 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)
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]

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

Change History (6)

comment:1 Changed 2 years ago by monoidal

Does this answer your question?

comment:2 in reply to:  1 Changed 2 years ago by 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

comment:3 Changed 2 years ago by int-e

#10249 and #11130 provide some rationale for the current behavior from ghc's side. See also

comment:4 Changed 2 years ago by int-e

Component: CompilerDocumentation
Description: modified (diff)
Summary: non-deferred typed hole despite -fdefer-typed-holesimprove documentation of -fdefer-typed-holes for naked expressions in ghci
Type: bugtask

comment:5 Changed 19 months ago by 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.

comment:6 Changed 19 months ago by simonpj

Keywords: DeferredErrors added
Note: See TracTickets for help on using tickets.