<div dir="ltr"><div>I've got to say that I'm rather uncomfortable with the type-based meaning ascription of this proposal.</div><div><br></div><div>That being said, we do need a lightweight way to add such modifiers to arrows (and anything which can appear to the left of an arrows such as fields of data constructors, whether in record notation or not (though I'm fine with requiring GADT notation when not a record, that's what we did with Linear Types)). There is a staggering amount of possible such modifiers which have been conceptualised.<br></div><div><br></div><div>By far, this is the least awful such proposal that I've seen. It's the first time that such a proposal looks even remotely usable.</div><div><br></div><div>So the pragmatic in me is inclined to accept as well.</div><div><br></div><div>The need for such a lightweight mechanism to annotate terms, though, is quite a bit less clear to me. Because type disambiguation is rather novel in GHC, I'd rather be prudent in this area, and stage the term bits as future work. Keep the design, and revisit it once we have experience with the mechanism for arrow modifiers.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 26, 2020 at 8:58 PM Alejandro Serrano Mena <<a href="mailto:trupill@gmail.com">trupill@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>
<div dir="ltr">Dear all,</div><div dir="ltr">This proposal suggests adding syntax for a general notion of modifiers, like the ones we’ve been talking about lately affecting linearity or matchability of arrows. For example, if linear types and unsaturated families are accepted as they stand, we would have `Int #1 -> @U Bool` (or something like that), whereas with this proposal we would have the more uniform `Int %1 %Unmatchable -> Bool`.</div><div dir="ltr"><br></div><div dir="ltr">Since the amount of modifiers is likely to increase in the future, I think it’s a great idea to agree and reserve such syntax, instead of coming up with different ways on each proposal. I thus recommend acceptance of this proposal.</div><div dir="ltr"><br></div><div dir="ltr">The proposal itself:</div><div dir="ltr">(1) introduces syntax for modifiers in types and defines how to type/kind check them,</div><div dir="ltr">(2) reserved such syntax for other uses in declarations and terms.</div><div dir="ltr"><br></div><div dir="ltr">I think the proposal still has its merits only with (1), even though I lean towards accepting both parts of it.</div><div dir="ltr"><br></div><div dir="ltr">Regards,</div><div dir="ltr">Alejandro<br><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On 21 Nov 2020 at 10:07:18, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</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>
Dear Committee,<br><br>this is your secretary speaking:<br><br>A syntax for modifiers<br>has been proposed by Richard Eisenberg (this time it’s true)<br><a href="https://github.com/ghc-proposals/ghc-proposals/pull/370" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/370</a><br><a href="https://dfinity.slack.com/archives/C01BJ73A893/p1605922403340800?thread_ts=1605913774.336600&cid=C01BJ73A893" target="_blank">https://dfinity.slack.com/archives/C01BJ73A893/p1605922403340800?thread_ts=1605913774.336600&cid=C01BJ73A893</a><br><br>I’ll propose Alejandro as the shepherd, as he has looked at i<br>t in detail already.<br><br>Please guide us to a conclusion as outlined in <br><a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br><br>Thanks,<br>Joachim<br>-- <br>Joachim Breitner<br> <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br> <a href="http://www.joachim-breitner.de/" target="_blank">http://www.joachim-breitner.de/</a><br><br><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><br>
</div>
</blockquote>
</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>