eric at seidel.io
Wed Jan 20 17:24:07 UTC 2016
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.
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.
More information about the ghc-devs