CallStack naming

[Eric Seidel]

On Wed, Jan 20, 2016, at 08:14, Simon Peyton Jones wrote:
> |  > * In principle you might have multiple call stacks kicking around
> |  >   at the same time
> |  >      boo :: (?a::CallStack, ?b::CallStack) => Int -> Int
> |  >   Now I'm not really sure what is supposed to happen about solving
> |  >   these constraints.  Perhaps it could be a feature, but it's not
> |  >   one anyone has asked for, and even having to think about it makes
> |  >   my head hurt.
> |  
> |  Ugh, I don't want to think about this either.
> 
> But if it's just a synonym, this is entirely possible to do.

True. I don't think it would cause problems for the solver, but it could
certainly be a pitfall for users.

> |  >    class ICallStack where
> |  >       callStack :: CallStack
> 
> 
> |  I think there's a problem with this approach. The new ability to
> |  freeze CallStacks relies on being able to construct new dictionaries
> |  on-the-fly for ImplicitParams. So if we were to re-implement
> |  CallStacks with their own class, we would have to copy the shadowing
> |  logic that we already have for ImplicitParams.
> 
> I don't understand the problem.  Can you be more specific.

I've written up a few notes about the proposal on the wiki.

https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations#AlternateProposal

The problem is that I don't know how to implement `withFrozenCallStack`
(included in the wiki) as a Haskell function if CallStacks aren't
implicit parameters under-the-hood.

> Regardless, it sounds as though we agreeing that the *user-visible*
> aspect should use this API.  So no more '?callstack' in the user API. 
> Right?

Indeed!