[Haskell-cafe] New type of expressions containing (error ...) includes noisy implicit parameter

[Oliver Charles]

Just a clarification - the presence of that parameter does not say "I use
call stack" but rather "I need *a* call stack". This subtle difference
means that you do need to know about this due to how stacks work in GHC. If
you use error and then don't also add that constraint yourself to your
function, youll only see part of the stack. Hence it more than just UX
noise - I have a decision to make, and building a call stack gas a cost.

Also, is this RC2? I thought this was now changed to use constraint kinds
and type alias the implicit parameter behind a nicer API.

On Sat, 13 Feb 2016 8:51 am 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]
>
> 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.
>
> We checked after the previous thread where ($) occurred in the book. ($)
> is in the second chapter of the book, which is the first chapter of Haskell
> code. Now we have to hand-wave something completely impossible for them to
> understand (chapter 2 is expressions, types are chapter 5) or edit ($) out
> of the book until they can understand it. We can't write it completely out
> of the book because ($) gets used all over the place and we don't want
> encountering it to throw them off.
>
>
> --- Chris Allen
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160213/42705652/attachment-0001.html>