New type of expressions containing (error ...) includes noisy implicit parameter

[Simon Marlow]

On 15 February 2016 at 13:40, Dan Doel <dan.doel at gmail.com> wrote:

> But that is a consequence of call stacks being implemented by
> threading a parameter through the calls, not of the fact that it shows
> up in the type. Without the change in type, the programmer wouldn't be
> informed there is any difference without looking at the core.
>

I'm not suggesting that the parameter should be hidden in the type! I agree
that would be much worse.

No, I'm arguing that it was bad that we lost sharing just by using
undefined (or error).  If adding a call to error somewhere in your code
changes its asymptotic performance, that's at the very least surprising.

Apologies for diverting the discussion.  I also think it's potentially bad
from an educational point of view that error/undefined have these
non-standard types, in fact I argued against using implicit call stacks in
other functions in base for this reason (amongst others), and fortunately
we've limited it to just these.

Cheers
Simon

In other words, this gives one reason why users _do_ care that stack
> information is being carried around, and might want to see it in the
> type; it can have a runtime performance impact (and likely not just
> for CAFs).
>
> -- Dan
>
> On Mon, Feb 15, 2016 at 5:12 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> > 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
> >
> > Cheers
> > Simon
> >
> >
> >>
> >> 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
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160215/51aeb6bc/attachment.html>