Proposal: Dot as Postfix Function Apply

Wed Nov 4 19:31:01 UTC 2015

This has been proposed before and rejected before on many separate
occasions.

(.) already has a complicated enough role in our lives being used for
qualified names as well as composition.

Just.Just already doesn't parse as you'd expect due to its double-life.
Giving it a third job breaks every f.g out there in user code and actively
worsens systems that already exist for this purpose that compose better.

I remain strongly in the -1 camp.

-Edward

On Wed, Nov 4, 2015 at 1:57 PM, Andrew Gibiansky <andrew.gibiansky at gmail.com
> wrote:

> 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.
>
> That is, code like
>
> print person.name
>
> would desugar to
>
> print (name person)
>
> and not to
>
> name (print person)
>
> This is something that can't be replicated with current Haskell and is the
> crux of the issue, I think.
>
> 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)
>
> -- Andrew
>
> On Wed, Nov 4, 2015 at 10:28 AM, Andrew Farmer <anfarmer at fb.com> wrote:
>
>> 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-
>> <http://hackage.haskell.org/package/lens-4.13/docs/Control-Lens-Operators.html#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=
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151104/128e1bb0/attachment.html>