From murdoch@dunc@n @end|ng |rom gm@||@com  Sat Dec  5 02:03:23 2020
From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch)
Date: Fri, 4 Dec 2020 20:03:23 -0500
Subject: [Rd] [External] Re:  New pipe operator
In-Reply-To: <alpine.DEB.2.21.2012041310130.3003@luke-Latitude-7480>
References: <e55c2093-0bb5-5f9b-5521-0ca8bdf35953@gmail.com>
 <CALyqOb8c1hHOSaMV+fqXTwpeOsP--KJ_t-oeqMYYafVXeNpqZg@mail.gmail.com>
 <7586e034-e287-0970-6480-f82d747b5445@gmail.com>
 <b98cf6d4-b856-2963-1882-9341384d141d@kogentum.hu>
 <alpine.DEB.2.21.2012041310130.3003@luke-Latitude-7480>
Message-ID: <d03c6867-4aa8-fa82-fe98-e706994dad3a@gmail.com>

On 04/12/2020 2:26 p.m., luke-tierney at uiowa.edu wrote:
> On Fri, 4 Dec 2020, D?nes T?th wrote:
> 
>>
>> On 12/4/20 3:05 PM, Duncan Murdoch wrote:
>>> ...
>>>
>>> It's tempting to suggest it should allow something like
>>>
>>>   ? mtcars |> subset(cyl == 4) |> lm(mpg ~ disp, data = .)
>>>
>>> which would be expanded to something equivalent to the other versions: but
>>> that makes it quite a bit more complicated.? (Maybe _ or \. should be used
>>> instead of ., since those are not legal variable names.)
>>
>> I support the idea of using an underscore (_) as the placeholder symbol.
> 
> I strongly oppose adding a placeholder. Allowing for an optional
> placeholder significantly complicates both implementing and explaining
> the semantics. For a simple syntax transformation to be viable it
> would also require some restrictions, such as only allowing a
> placeholder as a top level argument and only once. Checking that these
> restrictions are met, and accurately signaling when they are not with
> reasonable error messages, is essentially an unsolvable problem given
> R's semantics.

I don't think you read my suggestion, but that's okay:  you're 
maintaining it, not me.

Duncan Murdoch

> 
> The case where the LHS is to be passed as something other than the
> first argument is unusual. For me, having that case stand out by using
> a function expression makes it much easier to see and so makes the
> code easier to understand. As a wearer of progressive bifocals
> and someone whose screen is not always free of small dust particles,
> having to spot the non-standard pipe stages by seeing a placeholder,
> especially a . placeholder, is be a bug, not a feature.
> 
> Best,
> 
> luke
> 
>> Syntactic sugars work the the best if 1) they require less keystrokes and/or
>> 2) are easier to read compared to the "normal" syntax, and 3) can not lead to
>> unexpected bugs (which is a major problem with the magrittr pipe). Using '_'
>> fulfills all of these criteria since '_' can not clash with any variable in
>> the environment.
>>
>> Denes
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>



[Rd] [External] Re: New pipe operator
Duncan Murdoch