<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 February 2016 at 13:40, Dan Doel <span dir="ltr"><<a href="mailto:dan.doel@gmail.com" target="_blank">dan.doel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But that is a consequence of call stacks being implemented by<br>
threading a parameter through the calls, not of the fact that it shows<br>
up in the type. Without the change in type, the programmer wouldn't be<br>
informed there is any difference without looking at the core.<br></blockquote><div><br></div><div>I'm not suggesting that the parameter should be hidden in the type! I agree that would be much worse.<br><br>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.<br><br></div><div>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.<br></div><div><br></div><div>Cheers<br></div><div>Simon<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In other words, this gives one reason why users _do_ care that stack<br>
information is being carried around, and might want to see it in the<br>
type; it can have a runtime performance impact (and likely not just<br>
for CAFs).<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Dan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, Feb 15, 2016 at 5:12 AM, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br>
> On 13 February 2016 at 08:32, Christopher Allen <<a href="mailto:cma@bitemyapp.com">cma@bitemyapp.com</a>> wrote:<br>
>><br>
>> Prelude> let myList = [1, 2, 3 :: Integer]<br>
>> Prelude> let myList' = myList ++ undefined<br>
>> Prelude> :t myList<br>
>> myList :: [Integer]<br>
>> Prelude> :t myList'<br>
>> myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer]<br>
><br>
><br>
> Yes, and I think perhaps an even more worrying problem here is that by<br>
> adding the reference to undefined, myList went from being a thunk to being a<br>
> function.  That is, it will be re-evaluated each time it it used.  I made a<br>
> ticket about this: <a href="https://ghc.haskell.org/trac/ghc/ticket/11383" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/11383</a><br>
><br>
> Cheers<br>
> Simon<br>
><br>
><br>
>><br>
>> This is on by default and insofar as I've been able to try, it's avoidable<br>
>> in a default GHCi 8.0 REPL session. I'm glad I caught this before our book<br>
>> goes to print in a couple months. We'd managed to avoid talking about<br>
>> implicit parameters in 1,100+ pages of book but now we're forced to<br>
>> acknowledge their existence in the 4th of 32 chapters.<br>
>><br>
>> This slipped past the radar more stealthily than the earlier stages of BBP<br>
>> did for 7.10. I was hearing about BBP on the GHC Trac pretty early on for<br>
>> months on end. Was the thinking that people still used implicit parameters<br>
>> for anything or taught them? On the one hand, this is a nice change and<br>
>> something I personally attempted (and failed) to make easier in GHC 7.10.<br>
>> The implementation making the types noisy rankles and didn't seem necessary<br>
>> when I investigated it between 7.8 and 7.10.<br>
>><br>
>> Could you warn us when (educationally relevant?) stuff like this is coming<br>
>> down the pipe before the RC please? Ideally during the design phase. I think<br>
>> this was discussed as part of FTP to avoid future debacles.<br>
>><br>
>> This isn't just a pedagogical problem, this is a UX problem. The users<br>
>> don't _care_ that call stack information is being carried around. Why would<br>
>> they? It happens without any mention in the types in almost every other<br>
>> programming language.<br>
>><br>
>><br>
>> --- Chris Allen<br>
>><br>
>><br>
>> _______________________________________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
</div></div></blockquote></div><br></div></div>