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#Al... 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!