<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 March 2017 at 23:26, Roman Leshchinskiy <span dir="ltr"><<a href="mailto:rleshchinskiy@gmail.com" target="_blank">rleshchinskiy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I'm in a slightly difficult situation here since I quite dislike the<br>
current pattern synonyms extension. I'll try nonetheless.<br>
<span class="gmail-"><br>
On Tue, Mar 21, 2017 at 1:43 PM, Joachim Breitner<br>
<<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br>
> Hi,<br>
><br>
> Am Dienstag, den 21.03.2017, 00:55 -0500 schrieb Christopher Allen:<br>
>> Proposal #41 is constructor synonyms. This would allow users to<br>
</span>>> [...]<br>
<span class="gmail-">><br>
> it is worth pointing out that under this proposal,<br>
><br>
> constructor FireMissles :: IO ()<br>
> constructor FireMissles = fireMissles<br>
><br>
> (without a pattern) is also valid. In other words: The capitalization<br>
> of an identifier will no longer be of significance.<br>
><br>
> This makes me dislike the proposal.<br>
<br>
</span>I completely agree. In fact, this proposal is basically about allowing<br>
value variable names to start with an upper case letter so if we want<br>
to go that way then I'm not sure why the keyword 'constructor' is<br>
necessary at all. I would much prefer not to go that way, though, so<br>
I'm against #41.<span class="gmail-"><br></span></blockquote><div><br></div><div>Yes, I think I agree with this too.</div><div><br></div><div>The point of pattern synonyms is to let you define something that to the importer of a module looks exactly like a data constructor, while allowing the author of the module to change its implementation. It fills in a missing opportunity for abstraction in the language.</div><div><br></div><div>But constructor synonyms go much further than this, allowing you to define something that looks like a data constructor but doesn't behave anything like one. It drops the requirement that the constructor be expressible as a pattern. If you want to do this, define a function!</div><div><br></div><div>Why not solve the original problem by allowing a separate type signature on the constructor in the pattern synonym? There's already an example of this in the proposal:</div><div><br></div><div><div>pattern Zero :: (Eq a, Num a) => a</div><div>pattern Zero <- ((== 0) -> True) where</div><div> Zero :: Num a => a</div><div> Zero = 0</div></div><div> <br></div><div>(the proposal has the signature on Zero slightly wrong, I think). This seems like it would address the problem but without also overly generalising what a conid can represent, and avoids the issues with import/export.</div><div><br></div><div>Digressing a bit, I wish it were possible to write the pattern above as </div><div><br></div><div><div><div>pattern Zero :: (Eq a, Num a) => a</div><div>pattern Zero <- x | x == 0 where</div><div> Zero :: Num a => a</div><div> Zero = 0</div></div></div><div><br></div><div>because I think ViewPatterns were a mistake. But that's a proposal for another day :)</div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
>> Proposal #42 would add type signatures for bidirectional pattern<br>
>> synonym constructor functions.<br>
</span>>> [...]<br>
<br>
This seems sensible provided there is a strong relation between the<br>
types of the constructor and the pattern.<br>
<span class="gmail-"><br>
> The proposal does not address if the signatures of the constructor and<br>
> the signature of the pattern have to be in any way related. Possible<br>
> design choices are:<br>
> * May not differ in anything but the constraints.<br>
> * Must have the same return type.<br>
> * Must have the same outer type constructor in their return type.<br>
> * No relation.<br>
> This ought to be clarified.<br>
<br>
</span>This is a very good point. I'd be in favour of this proposal under the<br>
"May not differ in anything but the constraints" policy and against it<br>
under any of the other three. A looser relationship between the<br>
constructor function and the pattern makes code significantly harder<br>
to read and the proposal doesn't include any justification for such a<br>
looser relationship so I would go with the strongest requirement<br>
possible.<br>
<br>
Thanks,<br>
<br>
Roman<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@<wbr>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-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br>
</div></div></blockquote></div><br></div></div>