[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