<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 17, 2018, at 7:24 AM, Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; caret-color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="font-size: 12pt;" class="">Good point. I was going to say “behave like GADTs” where the variables in the header do not scope over the signatures; but unfortunately in class decls the variables in the header *<b class="">do</b>* scope over the (term-level) signatures.</span></div></div></blockquote><div><br class=""></div><div>It's even worse than this. Not only do they scope over term-level signatures, but they scope over associated type declarations. (Confusingly, they do not scope over associated type family default equations.)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; caret-color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="font-size: 12pt;" class=""><o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; caret-color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="font-size: 12pt;" class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; caret-color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="font-size: 12pt;" class="">Richard, what do you think? Maybe associated types should only be given kind signatures at the top level (alongside the kind signature for the class). That would at least be clear.</span></div></div></blockquote></div><br class=""><div class="">That would be clear and unambiguous, but quite awkward:</div><div class=""><br class=""></div><div class="">class C a where</div><div class=""> type F a b</div><div class="">type F :: ...</div><div class=""><br class=""></div><div class="">Why does one `type` appear in within the class but the other does not? We have some long-winded arguments here to answer that question, but it's all unsatisfying. I don't have a better idea, though.</div><div class=""><br class=""></div><div class="">Separately, we could just tack this new feature into -XKindSignatures instead of inventing a new extension.... but making a change to an extension as stable and as old as -XKindSignatures is unfortunate.</div><div class=""><br class=""></div><div class="">Richard</div></body></html>