Proposal: Dot as Postfix Function Apply

Wed Nov 4 19:32:56 UTC 2015

-1. This is a bad solution to a non-existent problem.
On Nov 4, 2015 2:31 PM, "Edward Kmett" <ekmett at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/3a177627/attachment-0001.html>