<div dir="ltr"><div>I don't think that the non-forking principle informs completely on the debate at hand. Even if the extensions are monotonic increases on the current language, even if an extension will either be merged into the next GHC20xx or scrapped, the question of splitting an extension in two still has validity. You may say: well, what if we adopt the type-level literals without adopting data kinds?<br></div><div><br></div><div>I must, at any rate, apologise: it's my role to get to a resolution on the question of extension policy. This is going slow, and I've paused the process during the recent discussion on stability (I'm currently at capacity for committee work). We definitely can't wait until the policy has been well-defined before we can make a decision on the proposal at hand.</div><div><br></div><div>I said I was unconvinced the last time around. I haven't changed opinion, but I'm happy to revise if presented with a sufficiently strong motivation.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 19 Oct 2023 at 09:07, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks for the helpful summary Vlad! Admittedly I hadn't grasped the nub of the issue until now.<br></div><div><br></div><div>Regarding: <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Unfortunately, we don't have a general policy that would clearly tell us which camp/paradigm is right.</div></blockquote><div><br></div><div>I
 think we actually do have a policy that's relevant here, see "Does not 
create a language fork" in 
<a href="https://github.com/ghc-proposals/ghc-proposals#review-criteria" target="_blank">https://github.com/ghc-proposals/ghc-proposals#review-criteria</a></div><div><br></div><div>This essentially says we are biased *against* the "customizable Haskell" position and in favour of the monotonically-increasing-set-of-language-features position.</div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 18 Oct 2023 at 17:30, Vladislav Zavialov <<a href="mailto:vlad.z.4096@gmail.com" target="_blank">vlad.z.4096@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="auto"><div dir="ltr">Dear Committee,<div><br></div><div>Back in March I initiated a discussion of #536 "Type-level literals as a separate language extension" by <span style="color:rgb(0,0,0)">Ross Paterson. </span><span style="color:rgb(0,0,0)">Quick recap: currently DataKinds controls promotion of ADTs and Symbol/Natural/Char literals. The proposal is to factor out promotion of literals into their own extension, </span><span style="color:rgb(0,0,0)">TypeLevelLiterals</span><span style="color:rgb(0,0,0)">.</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">I recommended acceptance but received mixed feedback. Summary of opinions:</span></div><div><span style="color:rgb(0,0,0)">Vlad: "rec: accept"</span></div><div><span style="color:rgb(0,0,0)">SPJ: "content to accept"</span></div><div><span style="color:rgb(0,0,0)">Joachim: "</span>unsure how that fits with the overall direction we have for namespaces"</div><div>Arnaud: "<span style="color:rgb(0,0,0)">unconvinced that it is worth yet one extra extension"</span></div><div><span style="color:rgb(0,0,0)">Richard: "</span><span style="color:rgb(0,0,0)">pretty strongly against"</span></div><div><span style="color:rgb(0,0,0)">Adam: "</span><span style="color:rgb(0,0,0)">avoid bundling together distinct features" (i.e. accept)</span></div><div><span style="color:rgb(0,0,0)">Chris: "</span><span style="color:rgb(0,0,0)">in favour"</span></div><div><span style="color:rgb(0,0,0)">Iavor (as ex-member): "</span><span style="color:rgb(0,0,0)">strongly in favor"</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><font color="#000000">Haven't yet expressed their opinion: Simon M. and Moritz.</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">So we have roughly 5 votes in-favor-or-don't-mind and 3 votes against-or-unconvinced. SPJ suggested that we simply count the votes, but after reading the discussion, I find that there's a deeper reason for disagreement. Essentially, we have two camps:</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">1. </font>"Let a thousand flowers bloom": <font color="#000000">Haskell should be customizable, built out of small extensions </font>à la carte. (A necessary implication here is that this gives rise to dialects of Haskell that depend on the set of enabled extensions)</div><div>2. "More extensions make me wince": Extensions are a necessary evil while we explore the language design space, and we shouldn't create them unnecessarily. (Language editions like GHC2021 help with that, allowing the users to forget about individual extensions and simply use a better/newer Haskell)</div><div><br></div><div>The 1st paradigm suggests that <span style="color:rgb(0,0,0)">TypeLevelLiterals should be factored out. </span><span style="color:rgb(0,0,0)">TypeLevelLiterals+TypeData form a dialect different from DataKinds with regards to name resolution, which some users might prefer. Let them have it, why not?</span><br></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">The 2nd paradigm suggests that breaking DataKinds into smaller extensions is counterproductive. Do we want fewer extensions or more extensions, after all? And as a steering committee, don't we have a clear direction in which we steer?</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div>Unfortunately, we don't have a general policy that would clearly tell us which camp/paradigm is right. And it's about time that we make a decision regarding #536, even if we don't have a policy to guide us.</div><div><br></div><div>Because of that, my new plan is to reject the proposal out of caution. We have at least one "strongly against", and it's enough to give me pause. It's probably better to stick to the status quo, at least until we develop a concrete stance w.r.t. fine-grained extensions. (Pardon a digression, but this also calls into question whether 448 is justified in splitting ScopedTypeVariables into ExtendedForAllScope, MethodTypeVariables, PatternSignatures. Maybe we don't want fine-grained extensions after all)</div><div><br></div><div>The new recommendation is to reject the proposal, but I still can't make this decision single-handedly. So let's do another round of discussion, only this time let's stick to practicalities, not general considerations. Is there anyone on the committee (or do we know someone) who needs <span style="color:rgb(0,0,0)">TypeLevelLiterals for practical reasons, not just as a matter of taste? For example,</span></div><div><span style="color:rgb(0,0,0)">1. You are writing a book and you want to introduce TypeLevelLiterals before DataKinds</span></div><div><span style="color:rgb(0,0,0)">2. You are developing or maintaining a library or application that needs TypeLevelLiterals but cannot use DataKinds</span></div><div><span style="color:rgb(0,0,0)">3. You are working on an alternative Haskell implementation and intend to support TypeLevelLiterals but not DataKinds</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">If any of the above (or similar) applies, speak up.</span></div><div><br></div><div>Vlad</div></div></div>
</div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>