New type of expressions containing (error ...) includes noisy implicit parameter
marlowsd at gmail.com
Mon Feb 15 10:12:31 UTC 2016
On 13 February 2016 at 08:32, Christopher Allen <cma at bitemyapp.com> wrote:
> Prelude> let myList = [1, 2, 3 :: Integer]
> Prelude> let myList' = myList ++ undefined
> Prelude> :t myList
> myList :: [Integer]
> Prelude> :t myList'
> myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer]
Yes, and I think perhaps an even more worrying problem here is that by
adding the reference to undefined, myList went from being a thunk to being
a function. That is, it will be re-evaluated each time it it used. I made
a ticket about this: https://ghc.haskell.org/trac/ghc/ticket/11383
> This is on by default and insofar as I've been able to try, it's avoidable
> in a default GHCi 8.0 REPL session. I'm glad I caught this before our book
> goes to print in a couple months. We'd managed to avoid talking about
> implicit parameters in 1,100+ pages of book but now we're forced to
> acknowledge their existence in the 4th of 32 chapters.
> This slipped past the radar more stealthily than the earlier stages of BBP
> did for 7.10. I was hearing about BBP on the GHC Trac pretty early on for
> months on end. Was the thinking that people still used implicit parameters
> for anything or taught them? On the one hand, this is a nice change and
> something I personally attempted (and failed) to make easier in GHC 7.10.
> The implementation making the types noisy rankles and didn't seem necessary
> when I investigated it between 7.8 and 7.10.
> Could you warn us when (educationally relevant?) stuff like this is coming
> down the pipe before the RC please? Ideally during the design phase. I
> think this was discussed as part of FTP to avoid future debacles.
> This isn't just a pedagogical problem, this is a UX problem. The users
> don't _care_ that call stack information is being carried around. Why would
> they? It happens without any mention in the types in almost every other
> programming language.
> --- Chris Allen
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs