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! _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
