[GHC] #14367: Lazy evaluation can be invalidated

GHC ghc-devs at haskell.org
Thu Oct 19 12:25:30 UTC 2017


#14367: Lazy evaluation can be invalidated
-------------------------------------+-------------------------------------
        Reporter:  vanto             |                Owner:  (none)
            Type:  bug               |               Status:  closed
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      Resolution:  invalid           |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Other             |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by vanto):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 before closing the ticket here two things:\\

 {{{-fdefer-typed-holes}}} and {{{-fdefer-type-errors}}} should not exist
 in GHC.
 either an expression is well-typed or it is not well-typed.
 but you, you invent a "naked" expression that will ultimately still
 make an error output from the compiler. you hide an existing error
 for what to do in the end? make the compiler create an error when
 calculating this expression.
 that's wonderful! it does not help. It serve no purpose.

 back to the ticket. Haskell is three main things. lambda-calculus,
 type inference and lazy evaluation. that's all. in this ticket I point
 the lazy evaluation.
 I repeat my question: why give a type to an expression that is known
 to be unusable by the program?(yes I know why, here it is rather an
 interrogative sentence).
 choose between two actions:
 - it is necessary to give a type to the expression and then to check if it
 is used.\\
 or\\
 - it is necessary to check the expression if it is used before giving a
 type to the expression. \\
 We can do it using an identity function, for
 instance.\\
 in both cases the lazy evaluation will not use this expression.
 Each well-formed expression has, by definition, a value. this value
 does not work since the expression is not used by the lazy
 evaluation. this value serve no purpose.
 I prefer the second action although this does not happen so in GHC.
 he would probably have thought of that from the beginning.
 moreover, the lazy evaluation must be given a high priority in
 relation to the priority of errors or warning.(in this precise case).\\
 anyway the type inference has already been changed in the past so
 why not once again?

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14367#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list