Proposal: Dot as Postfix Function Apply

[Andrew Farmer]

I'm a strong -1. This already exists as an operator anyway:

http://hackage.haskell.org/package/lens-4.13/docs/Control-Lens-Operators.ht
ml#v:-38-


On 11/4/15, 6:16 AM, "Libraries on behalf of Dominique Devriese"
<libraries-bounces at haskell.org on behalf of
dominique.devriese at cs.kuleuven.be> wrote:

>+1
>
>I'm convinced that this proposed extension would be extremely natural
>and practical if we give it a chance.  The fact that it may conflict
>with previous, less natural syntax choices (lens composition with .
>comes to mind) should not be counted against an opt-in extension.
>Lens packages could easily provide an alternative notation for their .
>for when the extension is enabled.
>
>Regards,
>Dominique
>
>2015-11-04 11:44 GMT+01:00 Jeremy <voldermort at hotmail.com>:
>> Dot as Postfix Function Apply
>> 
>>(https://urldefense.proofpoint.com/v2/url?u=https-3A__ghc.haskell.org_tra
>>c_ghc_wiki_Records_DeclaredOverloadedRecordFields_DotPostfix&d=CwICAg&c=5
>>VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnG
>>xAokec8hTZyMcwu8voE&s=ZxiyXvL6jUpla8Ikbdndqpoft7zJnvOGqHgicaQBP2I&e= )
>> was originally part of ORF, but dropped to keep the scope/discussion
>>more
>> manageable. Now that ORF is in for GHC 8.0, I would like to re-propose
>>dot
>> postfix syntax.
>>
>> The idea is that instead of
>>
>> (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person)
>>
>> we could have
>>
>> person.title ++ " " ++ person.firstName ++ " " ++ person.lastName
>>
>> This is a simple source-to-source translation with no changes to the
>>type
>> system (TDNR is an orthogonal proposal). The advantages are:
>>
>>   1. Code that's easier to read/write.
>>   2. Familiar to users of almost every other programming language.
>>   3. IDE auto-complete - an IDE can suggest functions applicable to the
>> variable after typing .
>>
>> This would be an opt-in extension.
>>
>> I'm posting this to the libraries list because that's where proposals
>> generally go, although this isn't strictly a library issue. If it
>>should be
>> on a different list I'll move it.
>>
>>
>>
>> --
>> View this message in context:
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__haskell.1045720.n5.na
>>bble.com_Proposal-2DDot-2Das-2DPostfix-2DFunction-2DApply-2Dtp5821620.htm
>>l&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjH
>>H3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=L_6yc68pNbnhlMLCkcHBSU8qXF8vWd69dLL7W
>>70W4uY&e= 
>> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> 
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-
>>2Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD
>>0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8t
>>vSWaEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e=
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2
>Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T
>3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8tvSW
>aEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e=