<span>I was thinking about a design where the linear arrow is a completely separate type than the normal function type. </span><div><br></div><div> I think that a choice like that would probably require additional annotations on other declarations to indicate when the linear machinery would kick in.  </div><div><br></div><div>For examplee, `data` declarations would need an extra tag to indicate that we should generate linear constructors, pattern matching, and single field selectors.</div><div><br></div><div>Similarly, to declare linear functions we would either require a type signature, or some sort of a tag on the lambda/function declaration to indicate that it is linear.</div><div><br></div><div>I haven't thought through all the details but this is what I was thinking about.</div><div><br></div><div>Essentially, the difference is that the current proposal keeps track of these tags automatically in the multiplicity of the function space and I was thinking of a design where these things are specified manually.</div><div><br></div><div>I imagine the biggest trade off is that the current proposal allows for polymorphism in the multiplicity, while I was thinking maybe we could start without.</div><div><br></div><div>I am not arguing for this alternative design as I haven't really thought through all the details.  I was just thinking of alternatives that leave the current function space alone.</div><div><br></div><div>As I said before, though, perhaps we should not worry that much about the function space, and just go for it.</div><div><br></div><div>I have some comments on the type functions for multiplicities, but I'll write them in the git hub.</div><div><br></div><div>Iavor</div><div><br></div><div><br><div dir="auto"><br></div><div dir="auto"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 29, 2018, 8:40 AM Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com">bravit111@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Now I get it, thank you for clarification. I agree with your recommendation. </span><div><br></div><div>Vitaly <br><br><div class="gmail_quote"><div dir="ltr">вт, 28 авг. 2018 г., 19:39 Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>>:<br></div></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Aug 28, 2018, at 9:32 PM, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank">bravit111@gmail.com</a>> wrote:</div><br class="m_-9100216728224442351m_8985303026893887017Apple-interchange-newline"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">I don't understand the meaning of "the road towards acceptance". Doesn't it mean discussing the proposal forever? I think we should accept it instead as it is or at least set strict timeframe for the final decision.</span></div></blockquote></div><br><div>This is a good point. The truth is that the committee has no experience dealing with a proposal of the size of this one. It's hard (for me) to accept this proposal as is, because it's not a full specification. The big missing piece is inference. We also don't have a solid description of how much complexity the implementation will have to adopt. Yet, it would be very unfortunate for the authors to put in a ton of time into writing a paper, a proposal, and a prototype implementation only to get turned down. So, my understanding is that I'm recommending something of a conditional acceptance: we say, as a committee, that we're pleased with the general direction of travel and to encourage the authors to keep working. This means that we expect to accept, barring something large and unforeseen. The difference between conditional acceptance and outright acceptance is that it gives the committee further opportunities to suggest amendments to the proposed change. (Even an accepted proposal can effectively get retroactively denied if, say, the implementation requires a 10% slowdown on all programs to support an esoteric feature.)</div><div><br></div><div>Does this help to clarify?</div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>Richard</div></div></blockquote></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></div></div>