CallStack naming

Eric Seidel eric at
Wed Jan 20 16:05:47 UTC 2016

On Wed, Jan 20, 2016, at 02:25, Simon Peyton Jones wrote:
> |  > undefined :: AppendsCallStack => a
> |  
> |  Seems simpler. Is it problems with a nullary class?
> Hmm.  Actually I think that's quite a good idea.

I agree, this is much nicer than enabling ImplicitParams and having to
remember the naming convention!

However, it seems to me that we could implement this as a constraint
synonym (pending Joachim's bug #11466). So the main benefit from giving
CallStack its own class would be in simplifying the implementation.

> There are disadvantages:
> * The special cases in the type checker need a 2-level pattern
>   match: for the magic "IP" class, and then the magic "CallStack" type

I don't think this is so bad, we already have a function isCallStackCt
that encapsulates the logic.

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

> Your alternative suggestion is to have a magic nullary class, the
> ICallStack class ("I" for implicit) so that
>    class ICallStack where
>       callStack :: CallStack
> At least that's is the implementation, but all the user can see is the
> overloaded function
>   callStack :: ICallStack => CallStack
> The solving rules, the CallStack type, and functions for printing it,
> would be precisely as now.
> I like this.  What about others?

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.

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


More information about the ghc-devs mailing list