<div dir="ltr">I'm not on either side of this fence yet, but keep in mind that this can't just be done with an operator, because, if I understand the proposal correctly, the proposed dot hack would have a precedence *higher* than function application. <div><br></div><div>That is, code like</div><div><br></div><div>print <a href="http://person.name">person.name</a></div><div><br></div><div>would desugar to</div><div><br></div><div>print (name person)</div><div><br></div><div>and not to</div><div><br></div><div>name (print person)</div><div><br></div><div>This is something that can't be replicated with current Haskell and is the crux of the issue, I think.</div><div><br></div><div>As Chris Done said, "All of this because Haskellers are allergic to parentheses." (A true comment, if perhaps one I maybe don't agree with)</div><div><br></div><div>-- Andrew</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 4, 2015 at 10:28 AM, Andrew Farmer <span dir="ltr"><<a href="mailto:anfarmer@fb.com" target="_blank">anfarmer@fb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm a strong -1. This already exists as an operator anyway:<br>
<br>
<a href="http://hackage.haskell.org/package/lens-4.13/docs/Control-Lens-Operators.ht
ml#v:-38-" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/lens-4.13/docs/Control-Lens-Operators.ht<br>
ml#v:-38-</a><br>
<br>
<br>
On 11/4/15, 6:16 AM, "Libraries on behalf of Dominique Devriese"<br>
<<a href="mailto:libraries-bounces@haskell.org">libraries-bounces@haskell.org</a> on behalf of<br>
<span class=""><a href="mailto:dominique.devriese@cs.kuleuven.be">dominique.devriese@cs.kuleuven.be</a>> wrote:<br>
<br>
>+1<br>
><br>
>I'm convinced that this proposed extension would be extremely natural<br>
>and practical if we give it a chance.  The fact that it may conflict<br>
>with previous, less natural syntax choices (lens composition with .<br>
>comes to mind) should not be counted against an opt-in extension.<br>
>Lens packages could easily provide an alternative notation for their .<br>
>for when the extension is enabled.<br>
><br>
>Regards,<br>
>Dominique<br>
><br>
>2015-11-04 11:44 GMT+01:00 Jeremy <<a href="mailto:voldermort@hotmail.com">voldermort@hotmail.com</a>>:<br>
>> Dot as Postfix Function Apply<br>
>><br>
</span>>>(<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__ghc.haskell.org_tra" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__ghc.haskell.org_tra</a><br>
>>c_ghc_wiki_Records_DeclaredOverloadedRecordFields_DotPostfix&d=CwICAg&c=5<br>
>>VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnG<br>
>>xAokec8hTZyMcwu8voE&s=ZxiyXvL6jUpla8Ikbdndqpoft7zJnvOGqHgicaQBP2I&e= )<br>
<span class="">>> was originally part of ORF, but dropped to keep the scope/discussion<br>
>>more<br>
>> manageable. Now that ORF is in for GHC 8.0, I would like to re-propose<br>
>>dot<br>
>> postfix syntax.<br>
>><br>
>> The idea is that instead of<br>
>><br>
>> (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person)<br>
>><br>
>> we could have<br>
>><br>
>> person.title ++ " " ++ person.firstName ++ " " ++ person.lastName<br>
>><br>
>> This is a simple source-to-source translation with no changes to the<br>
>>type<br>
>> system (TDNR is an orthogonal proposal). The advantages are:<br>
>><br>
>>   1. Code that's easier to read/write.<br>
>>   2. Familiar to users of almost every other programming language.<br>
>>   3. IDE auto-complete - an IDE can suggest functions applicable to the<br>
>> variable after typing .<br>
>><br>
>> This would be an opt-in extension.<br>
>><br>
>> I'm posting this to the libraries list because that's where proposals<br>
>> generally go, although this isn't strictly a library issue. If it<br>
>>should be<br>
>> on a different list I'll move it.<br>
>><br>
>><br>
>><br>
>> --<br>
>> View this message in context:<br>
</span>>><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__haskell.1045720.n5.na" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__haskell.1045720.n5.na</a><br>
>>bble.com_Proposal-2DDot-2Das-2DPostfix-2DFunction-2DApply-2Dtp5821620.htm<br>
>>l&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjH<br>
>>H3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=L_6yc68pNbnhlMLCkcHBSU8qXF8vWd69dLL7W<br>
>>70W4uY&e=<br>
<span class="">>> Sent from the Haskell - Libraries mailing list archive at Nabble.com.<br>
>> _______________________________________________<br>
>> Libraries mailing list<br>
>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
>><br>
</span>>><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-</a><br>
>>2Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD<br>
>>0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8t<br>
>>vSWaEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e=<br>
<span class="">>_______________________________________________<br>
>Libraries mailing list<br>
><a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
</span>><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2</a><br>
>Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T<br>
>3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8tvSW<br>
>aEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e=<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>