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