
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks for kicking off this conversation, Arnaud!<div class=""><br class=""></div><div class="">To be clear in this thread: I'm fine delaying the discussion of section 6-8 until later.</div><div class=""><br class=""></div><div class="">Arnaud brings up my new principles in his initial email. Do please consider these principles as part of the deliberations, as they will become principles that we, as a committee, will have adopted.</div><div class=""><br class=""></div><div class="">About extensions: We, as a community and as a committee, have not come to terms with the two possible interpretations of extensions. I would like to say that, ideally, extensions are candidates for eventual inclusion. However, that is neither the current practice nor our trendline. Examples:</div><div class=""> - any flags included in Haskell98 (including, for example, MonomorphismRestriction). These are definitely settings that one can choose per module. If they were candidates for inclusion, they wouldn't exist (because they're already included!).</div><div class=""> - RebindableSyntax (though this is not one to mimic)</div><div class=""> - MagicHash. My interpretation is that this extension is meant to allow users to explicitly opt into low-level code.</div><div class=""> - Recently accepted <a href="https://github.com/ghc-proposals/ghc-proposals/pull/285" class="">#285</a>, which introduces two new -XNo... extensions (both also included in #448).</div><div class="">As a practical matter, then, extensions are means of customization. We might imagine a debate where we try to change this, and then come up with a way to get from where we are to that changed future.</div><div class=""><br class=""></div><div class="">Very specifically answering Simon M's concern: I see ExtendedForAllScope as a dead end, yes. It's included as a way of supporting the gobs and gobs and gobs of code that use today's ScopedTypeVariables, but at t=∞, we should get rid of it. Note that an <a href="https://github.com/goldfirere/ghc-proposals/blob/type-variables/proposals/0448-type-variable-scoping.rst#58alternatives" class="">optional extra</a> introduces a @(..) syntax that makes TypeAbstractions significantly less repetitive, and thus about as easy to use as ExtendedForAllScope (which, recall, requires an explicit forall where there might otherwise be none).</div><div class=""><br class=""></div><div class="">Richard</div><div class=""><br class=""></div><div class="">PS: I'm on holiday starting tomorrow and so may not respond for about two weeks. Back in action on the 15th, but expect a few days of digging out.</div></body></html>