#14367: Lazy evaluation can be invalidated -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Evaluating arguments only if and when they are needed. This is the first principle of lazy evaluation.\\ Example:\\ {{{ Prelude> let f True x y = x Prelude> f True 3 (3/0) 3 }}} Good answer! See this:\\ {{{ Prelude> f True 8 undefined 8 }}} and:\\ {{{ Prelude> f True undefined 8 *** Exception: Prelude.undefined CallStack (from HasCallStack): error, called at libraries\base\GHC\Err.hs:79:14 in base:GHC.Err undefined, called at <interactive>:2:8 in interactive:Ghci2 }}} These results are all correct because the evaluated expression (function) is non-strict.\\ The same expression below with a changed argument:\\ {{{ Prelude> f True 3 _ <interactive>:54:10: error: * Found hole: _ :: p20 Where: `p20' is an ambiguous type variable * In the third argument of `f', namely `_' In the expression: f True 3 _ In an equation for `it': it = f True 3 _ * Relevant bindings include it :: p1 (bound at <interactive>:54:1) }}} I understand this error, it is legitimate except that here, in this specific case, I would never use this expression.( i.e{{{_}}}) or the result of that expression if that result were to be used. Here the error message should not have priority. \\ This argument ( i.e {{{_}}}) does not need to be evaluated to calculate the result.\\ With Normal-Order Reduction, an expression is reduced only when absolutely necessary to continue the reduction.\\ So, here, who cares! Since this expression (i.e{{{_}}}), or the result is supposed never to be used.\\ It is the same for this example:\\ {{{ Prelude> f True 3 r <interactive>:55:10: error: Variable not in scope: r }}} Idem, here the error message should not have priority. About {{{r}}} here, who cares! \\ By contrast here in this other example,{{{r}}} must be in the scope to be used:\\ {{{ Prelude> let g x t = x + t + r <interactive>:56:21: error: Variable not in scope: r }}} Anyway,{{{(+)}}} is strict in both arguments.\\ I think leaving the priority to lazy evaluation will bring much more consistency in the results. Of course, ghc would take this error into account and send it after the compilation if needed. \\ These examples are not exaustive examples. See ticket [ticket:14355]. (although in this ticket, the thing is slightly different). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14367 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler