[GHC] #13557: error found hole: _ is not appropriate in the following case
GHC
ghc-devs at haskell.org
Tue Apr 11 13:43:16 UTC 2017
#13557: error found hole: _ is not appropriate in the following case
-------------------------------------+-------------------------------------
Reporter: vanto | Owner: (none)
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Incorrect | Unknown/Multiple
error/warning at compile-time | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Changes (by vanto):
* status: closed => new
* resolution: invalid =>
Comment:
Reply to simonpj.\\
Thanks.\\
I reopen this ticket in order to bring clarity to what I mean.
"... The goal of typed holes is to help with writing Haskell code rather
than to change the type system..." \\
I agree with Typed Holes.
Here I would like to point out a matter of logical sense.
{{{f' = [True | s <- [_, _]]}}} immediately raise an error. This behaviour
is in conformity. Of course. But it is not necessarily correct. It will be
noted that it is a single function in this context.
But if {{{f'}}}is written in {{{f}}} at the end of other functions, this
error has no logical sense.\\
Consider {{{undefined}}}.
{{{g = [r | r <- [undefined, undefined]]}}}. the result is
{{{Exception: Prelude.undefined}}}.\\
But if {{{g = [1 | r <- [undefined, undefined]]}}} the result is
{{{[1,1]}}}.\\
It is as if there was no computation of {{{undefined}}}.\\
We can have the same effect if we have functions in the list as:\\
{{{h = [1 | r <- [(\x -> x*3), (\y -> y+1)]]}}}.\\
\\
Here, the function {{{f'}}} write at the end of the function {{{f}}}
should play the same behaviour from a logical point of view.\\
It should also be noted that the error happens right away.\\
If the error was delayed the function {{{f'}}} would behave as with
{{{undefined}}}.\\
Perhaps it is here that we must change the behavior where the error
occurs?\\
In fact, it's a bit like if GHC would produce the error during the
reading of {{{_}}} from the list as {{{[_, _]}}} instead of producing the
error during the computation of {{{_}}}. \\
Do you understand?\\
And what do others think?\\
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13557#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list