CallStack naming

[Joachim Breitner]

Hi,

Am Mittwoch, den 20.01.2016, 00:39 -0500 schrieb Richard Eisenberg:
> I'm sure there's an easy answer to this, but I'm wondering: why is
> the CallStack feature implemented with implicit parameters instead of
> just a magical constraint? Whenever I use this feature, I don't want
> to have to enable -XImplicitParams and then make sure I get the name
> right. What would be wrong with, e.g.,
> 
> > undefined :: AppendsCallStack => a
> 
> Seems simpler. Is it problems with a nullary class?

I tried to construct this using what we have right now:

==> AppendCallStack.hs <==
{-# LANGUAGE ConstraintKinds, ImplicitParams #-}
module AppendCallStack (AppendsCallStack) where

import GHC.Stack

type AppendsCallStack = ?x::CallStack

==> Bar.hs <==
module Bar where

import AppendCallStack

foo x :: AppendsCallStack => a -> a
foo x = error "Test"

But with GHC-7.10 I get

    [1 of 2] Compiling AppendCallStack  ( AppendCallStack.hs, AppendCallStack.o )
    [2 of 2] Compiling Bar              ( Bar.hs, Bar.o )
    Bar.hs:5:1:
        Invalid type signature: foo x :: AppendsCallStack => a -> a
        Should be of form <variable> :: <type>

although the constraint seems to be a constraint all right:

    *AppendCallStack> :kind AppendsCallStack 
    AppendsCallStack :: GHC.Prim.Constraint

and with GHC HEAD I get

    [1 of 2] Compiling AppendCallStack  ( AppendCallStack.hs, AppendCallStack.o )

    AppendCallStack.hs:6:1: error:
        • Illegal implicit parameter ‘?x::CallStack’
        • In the type synonym declaration for ‘AppendsCallStack’

Too bad...

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160120/9f04417a/attachment.sig>