<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi GHCSC,<div class=""><br class=""></div><div class="">I am the shepherd for Proposal #402, which has been submitted for our consideration.</div><div class=""><br class=""></div><div class="">Proposal text: <a href="https://github.com/serokell/ghc-proposals/blob/gadt-syntax/proposals/0000-gadt-syntax.rst" class="">https://github.com/serokell/ghc-proposals/blob/gadt-syntax/proposals/0000-gadt-syntax.rst</a></div><div class="">PR discussion: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/402" class="">https://github.com/ghc-proposals/ghc-proposals/pull/402</a></div><div class=""><br class=""></div><div class="">-----------------</div><div class=""><b class="">Proposal Summary:</b></div><div class=""><br class=""></div><div class="">The proposal changes a few aspects of GADT constructor syntax, in part to make them simpler, and in part to make them more expressive. Only non-record syntax is treated by this proposal; GADT record constructors are entirely unaffected.</div><div class=""><br class=""></div><div class="">The two changes are:</div><div class=""><br class=""></div><div class="">1. Drop support for parentheses around result types in GADT constructor signatures.</div><div class="">2. Add support for nested quantifiers in GADT constructor signatures.</div><div class=""><br class=""></div><div class="">Examples & motivation:</div><div class=""><br class=""></div><div class="">1. This would now be rejected:</div><div class=""><br class=""></div><div class="">data T where</div><div class=""> MkT :: Int -> (Bool -> T)</div><div class=""><br class=""></div><div class="">Those parentheses are not allowed.</div><div class=""><br class=""></div><div class="">On the other hand</div><div class=""><br class=""></div><div class="">data S where</div><div class=""> MkS :: Int -> Bool -> (S)</div><div class=""><br class=""></div><div class="">remains accepted.</div><div class=""><br class=""></div><div class="">This change is mainly to simplify the implementation, but it also helps users understand that the thing after `MkS ::` really is not a type: it's a list of constructor arguments written in a concrete syntax that looks like a type. See the proposal for more explanation of how this is not a type.</div><div class=""><br class=""></div><div class="">2. This would now be accepted:</div><div class=""><br class=""></div><div class="">data Q a where</div><div class=""> MkQ :: forall e. Int -> e -> forall a -> forall b. a -> b -> Show a => Q (a,b)</div><div class=""><br class=""></div><div class="">Note the appearance of `forall a ->`, `forall b.`, and `Show a =>` after visible arguments.</div><div class=""><br class=""></div><div class="">Constructors with forall ... -> syntax (such as our MkQ) will not be allowed in expressions or patterns (that would require #281), but will be allowed in types.</div><div class=""><br class=""></div><div class="">This change is a generalization of the syntax we have today, and it allows library authors more flexibility in designing interfaces, as they can now choose where type arguments should be written in a constructor.</div><div class=""><br class=""></div><div class="">------------------------</div><div class=""><b class="">Recommendation:</b></div><div class=""><b class=""><br class=""></b></div><div class="">I recommend acceptance.</div><div class=""><br class=""></div><div class="">1. Dropping the parentheses sounds trivial, but keeping them means we have to do extra work in the design of our data structures to remember the parentheses. Because constructor "types" aren't types, this information isn't otherwise needed.</div><div class=""><br class=""></div><div class="">2. This generalization increases our expressiveness and removes what may feel like an artificial limitation. Furthermore, it is necessary in the case where we might have later arguments depend on earlier ones (possible for promoted constructors).</div><div class=""><br class=""></div><div class="">Please share opinions on acceptance/rejection here, or technical thoughts on the ticket itself.</div><div class=""><br class=""></div><div class="">I will accept in two weeks if there are no objections.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class="">Richard</div><div class=""><br class=""></div></body></html>