<div dir="ltr"><div>I suspect we are in agreement here.  What I was trying to capture is the fact that in my experience papers tend to contain both more and less than what I'd expect to find in a GHC proposal.</div><div><br></div><div>They contain more, in that they may address important issues such as proofs of soundness, or other important properties, much more extended motivation, comparisons to other research, etc..  I don't think these belong in a proposal, but I think it is a big plus for a proposal to refer to a published papers addressing such issues.</div><div><br></div><div>I think, however, sometimes (often?) papers also tend to aim at a fairly general explanation of concepts, that is not specific to a particular language.  Â I think that GHC proposal should contain this extra detail, and be aimed at how the feature would be added to Haskell in particular (and even more concretely, to GHC).  Â This involves discussing concrete syntax, interactions with other language features, and a lot of examples, so that a Haskell user can get a feel of what the new feature might feel like.</div><div><br></div><div>Overall, I am a bit weary of publishing a list of "requirements" for a proposal, mostly because anything we publish could probably be interpreted in different ways, and I think---for me---it is much more important that we collectively think the proposal is a good idea, than there being a check-list that has been completely checked-off. </div><div><br></div><div>-Iavor<br><div><br></div><div><br><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 28, 2017 at 2:25 AM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div class="m_1459663315698940415m_-6999761418007387233WordSection1">
<p class="MsoNormal" style="margin-left:36.0pt">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div></div><div lang="EN-GB" link="blue" vlink="purple"><div class="m_1459663315698940415m_-6999761418007387233WordSection1"><p class="MsoNormal">I don’t really agree with this.  Papers tend to be the result of a great deal of focused attention and multiple iterations.  It’s hard (and indeed wasteful) to duplicate that effort in a proposal.  Better just to point to it. (On the rare
 occasions where there is a paper that squarely addresses the topic of the proposal.)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">But yes, more examples (not duplicate examples) are always good.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Simon<span style="font-size:12.0pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Iavor Diatchki [mailto:<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>]
<br>
<b>Sent:</b> 28 November 2017 02:16<br>
<b>To:</b> Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>><br>
<b>Cc:</b> Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>>; <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>; Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>><br>
<b>Subject:</b> Re: [ghc-steering-committee] What do we need from the linear-types proposal?<u></u><u></u></span></p>
</div>
</div></div></div></div><div lang="EN-GB" link="blue" vlink="purple"><div class="m_1459663315698940415m_-6999761418007387233WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Hello,<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
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):<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
  Â 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. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
  Â 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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
-Iavor<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
  Â <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
 <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Mon, Nov 27, 2017 at 2:04 PM Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<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" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><u></u><u></u></p>
</blockquote>
</div>
</div></div></div></blockquote></div></div></div>