[GHC] #1488: Code that won't ever be executed should not give rise to constraints

[GHC]

#1488: Code that won't ever be executed should not give rise to constraints
----------------------------------+-----------------------------------------
    Reporter:  iampure at gmail.com  |        Owner:                  
        Type:  feature request    |       Status:  new             
    Priority:  normal             |    Milestone:                  
   Component:  Compiler           |      Version:  6.6.1           
    Severity:  normal             |   Resolution:                  
    Keywords:                     |   Difficulty:  Moderate (1 day)
          Os:  Unknown            |     Testcase:                  
Architecture:  Unknown            |  
----------------------------------+-----------------------------------------
Old description:

> In the code
>
> a x = let b = show x in 5,
> ghci derives:
> a :: (Show a, Num t) => a -> t, which is correct, but I think the rules
> should be slightly altered, since in reality giving something to a which
> is not an instance of Show wouldn't be a problem, since it's not used in
> the first place.
>
> One important application of this is testing a general data structure for
> one specific element type with assertions in the the general code and
> having a switch to turn generic and non-generic mode on and off.
> Unfortunately, this approach doesn't work today, since all kinds of
> constraints that are essentially part of the debugging process get added.
> Since deciding whether a certain variable is used is very easy in this
> setting(for example CPP macros that expand into "if debugging", where
> debugging will have a constant value. (I don't expect you to solve the
> Halting Problem).

New description:

 In the code
 {{{
 a x = let b = show x in 5,
 }}}
 ghci derives:
 {{{
 a :: (Show a, Num t) => a -> t,
 }}}
 which is correct, but I think the rules should be slightly altered, since
 in reality giving something to a which is not an instance of Show wouldn't
 be a problem, since it's not used in the first place.

 One important application of this is testing a general data structure for
 one specific element type with assertions in the the general code and
 having a switch to turn generic and non-generic mode on and off.
 Unfortunately, this approach doesn't work today, since all kinds of
 constraints that are essentially part of the debugging process get added.
 Since deciding whether a certain variable is used is very easy in this
 setting(for example CPP macros that expand into "if debugging", where
 debugging will have a constant value. (I don't expect you to solve the
 Halting Problem).

Comment (by simonpj):

 Lennart adds:  And ghci gives the only sensible answer.  Once you start
 trying to be clever you're on the slippery slope to undecidability.  How
 would one know where to stop?  I would be most perturbed if Haskell were
 to try and ignore "unused" variables.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1488>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
-------------- next part --------------
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs