CallStack naming

[Simon Peyton Jones]

|  > * 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.

|  >    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.

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?

Would you like to start amending the wiki page with the proposed new design, from the user point of view. We can continue to argue about implementation!

|  So I'm in favor of Joachim's constraint synonym.

Currently I'm not :-)

Simon