[Haskell-cafe] HasCallStack - runtime costs?

[Eric Seidel]

On Sat, Mar 5, 2016, at 03:46, Michael Sloan wrote:
> I tried it out, and it does have compatibility with the implicit
> parameter
> still!  Good stuff.

It is still an implicit parameter under the hood, but we're trying to
hide it because we don't really care about the name of the implicit
parameter. In a future release we may decide to replace the implicit
parameter with a custom extension to the constraint solver, so I would
avoid using the implicit parameter :)

> However, I was making use of a potentially unintentional aspect
> of the 7.10 API, which is that `getCallStack` can be used in a record
> update of `CallStack`.  This is useful for annotating callstacks with
> helpful debugging info, like the arguments used for an invocation.
> The existing format for the message works quite well for this, since
> it's just the function name.  So, appending parameters results in
> "fn a1 a2 a3", etc.
> 
> Is it too late in the GHC release cycle to have add an additional
> GHC.Stack.Internal module which enables modification of CallStack?

This is probably the main source of backwards-incompatiblity. CallStack
is no longer a simple wrapper around a [(String,SrcLoc)], so the record
update trick can't be done. Instead you should be able to extract the
list as before with getCallStack, tweak it to your liking, and then make
a new CallStack with GHC.Stack.fromCallSiteList (I'm not sure if that
went in before RC2 but it is in the branch).

The other backwards-incompatibility that springs to mind is that
show{CallStack,SrcLoc} were renamed to pretty{CallStack,SrcLoc}.

> Does your work on the callstack stuff (thanks!) introduce backwards
> compatibility issues?  I'm working on a library that will make extensive
> use of 7.10's implementation of callstacks.

Cool! Just be aware that 7.10's implementation had a nasty bug that
broke the chain between a CallStack in the context and a use of the
CallStack inside a let-binder.

Eric