CallStack naming

[Simon Peyton Jones]

OK. Let's make sure the wiki page and documentation reflects this.

Thanks

SImon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Eric
|  Seidel
|  Sent: 27 January 2016 18:16
|  To: ghc-devs at haskell.org
|  Subject: Re: CallStack naming
|  
|  On Thu, Jan 21, 2016, at 04:07, Simon Peyton Jones wrote:
|  > |  It’d probably need a built-in function
|  > |
|  > |  setCallStack :: CallStack -> (AppendsCallStack => a) -> a
|  >
|  > Correct. This is easy to write in Core but not in Haskell.
|  
|  Ugh, I just realized that we can't write setCallStack (with implicit
|  parameters) in Haskell either. Well, we can, but it adds an entry to
|  the stack.. Why? Let's look at the implementation
|  
|    setCallStack :: CallStack -> (HasCallStack => a) -> a
|    setCallStack stk do_this =
|      let ?callStack = stk in do_this
|  
|  Rebinding ?callStack works just fine, but the occurrence of do_this
|  causes GHC to push an entry onto the stack, which is less than ideal.
|  
|  What does this look like in practice? If we evaluate
|  
|    setCallStack foo (error "die")
|  
|  the resulting stack will be
|  
|    error
|    *do_this*
|    foo
|  
|  The rebinding trick works for withFrozenCallStack precisely because we
|  freeze the CallStack, so the push from do_this is ignored.
|  
|  So, long story short, I'm not convinced of the utility of setCallStack.
|  I think perhaps we should not provide it, and just do the rebinding
|  trick inside withFrozenCallStack (which was the only use-case for
|  setCallStack to begin with).
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c37a3c50163ce4
|  0dc0ee408d32745f348%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=dVg%2b
|  q2D%2b2mgmgSWh8Ic9o09P%2f9mem4CpDgd0YzZZpPc%3d