[GHC] #14367: Lazy evaluation can be invalidated

[GHC]

#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