<div dir="ltr">Hello,<div><br></div><div>Coming up with a concrete list of suggestions is hard, but here are a couple things that would make it easier for me to understand large proposals (e.g., like the linear types one):</div><div><br></div><div>   1. It is good if large proposals are "modular", meaning that you can understand them (and perhaps implement them), one piece at a time.  For example, adding certain features to the language may enable us to make library changes, but that sort of thing can be disused separately. </div><div><br></div><div>   2. I think that it would be good if the proposal contains enough information to get a feeling for the core idea of the proposal, both how it might be used, and about how it might be implemented, without referring to external papers.   One thing that works well for me is to see lots of examples which illustrate various aspects of the design.  Generally, I find it much easier to understand and generalize from a set of examples, than a set of rules, especially if the rules are not accompanied by an explanation of the reasons for choosing them.</div><div><br></div><div>-Iavor</div><div>   </div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 27, 2017 at 2:04 PM Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu">rae@cs.brynmawr.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Nov 27, 2017, at 9:58 AM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br>
><br>
> * If a proposal requires a change to Core, that change should be<br>
>  described rather precisely.<br>
<br>
In Greek or in Haskell? Less tersely: does a formalization in a paper suffice? Or should the proposal write out the new Haskell definition? These are closely related, but not the same. (For example, formalizations don't include the AppTy/TyConApp/FunTy distinction that is important for performance.)<br>
<br>
My own view is that Greek is enough.<br>
<br>
Richard<br>
_______________________________________________<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>