[Rd] New pipe operator
Avi Gross
@v|gro@@ @end|ng |rom ver|zon@net
Sun Dec 6 20:03:23 CET 2020
Topic is more about anonymous functions but also pipes.
Rui thought the proposed syntax was a bit ugly. I assume the \(x) ... was what he means, not the function(x)... version.
Many current languages have played games on adding some form of anonymous function that is defined and used in place. Some go to great pains to make various parts optional to the point where there are many valid way to create a function that takes no arguments so you can leave out almost everything else as optional.
I admit having to type "lambda" all the time (in some languages) is not preferable but in English, something shorter like fun(...) or func(...) instead of function(...) might be more readable than the weird choice of \(. Yes. You can view the combo to bring attention to the fact the "(" is meant not as any old paren for other uses but specifically for function invocation/definition purposes. But overuse of the backslash to mean other things such as in regular expressions and the parentheses for so many things, makes parsing for humans harder. So does "|>" for the new pipe symbol as it can also look like "or greater than" and since some humans do not insert spaces to make code even shorter, it can be a challenge to rapidly see a line of code as tokens.
If programming were being invented today with a larger set of symbols, it might use more of them and perhaps look more like APL. We might have all of the built-in to the language tokens be single symbols including real arrows instead of -> and a not-equals symbol like ≠ instead of != or ~= s some languages use. In that system, what might the pipe symbol look like?
ǂ
But although making things concise is nice, sometimes there is clarity in using enough room, to make things clear or we might as well code in binary.
-----Original Message-----
From: R-devel <r-devel-bounces using r-project.org> On Behalf Of Rui Barradas
Sent: Sunday, December 6, 2020 2:51 AM
To: Gregory Warnes <greg using warnes.net>; Abby Spurdle <spurdle.a using gmail.com>
Cc: r-devel <r-devel using r-project.org>
Subject: Re: [Rd] New pipe operator
Hello,
If Hilbert liked beer, I like "pipe".
More seriously, a new addition like this one is going to cause problems yet unknown. But it's a good idea to have a pipe operator available. As someone used to magrittr's data pipelines, I will play with this base one before making up my mind. I don't expect its behavior to be exactly like magrittr "%>%" (and it's not). For the moment all I can say is that it is something R users are used to and that it now avoids loading a package.
As for the new way to define anonymous functions, I am less sure. Too much syntatic sugar? Or am I finding the syntax ugly?
Hope this helps,
Rui Barradas
Às 03:22 de 06/12/20, Gregory Warnes escreveu:
> If we’re being mathematically pedantic, the “pipe” operator is
> actually function composition > That being said, pipes are a simple
> and well-known idiom. While being less
> than mathematically exact, it seems a reasonable label for the (very
> useful) behavior.
>
> On Sat, Dec 5, 2020 at 9:43 PM Abby Spurdle <spurdle.a using gmail.com> wrote:
>
>>> This is a good addition
>>
>> I can't understand why so many people are calling this a "pipe".
>> Pipes connect processes, via their I/O streams.
>> Arguably, a more general interpretation would include sockets and files.
>>
>> https://en.wikipedia.org/wiki/Pipeline_(Unix)
>> https://en.wikipedia.org/wiki/Named_pipe
>> https://en.wikipedia.org/wiki/Anonymous_pipe
>>
>> As far as I can tell, the magrittr-like operators are functions (not
>> pipes), with nonstandard syntax.
>> This is not consistent with R's original design philosophy, building
>> on C, Lisp and S, along with lots of *important* math and stats.
>>
>> It's possible that some parties are interested in creating a kind of
>> "data pipeline".
>> I'm interested in this myself, and I think we could discuss this more.
>> But I'm not convinced the magrittr-like operators help to achieve
>> this goal.
>> Which, in my opinion, would require one to model programs as directed
>> graphs, along with some degree of asynchronous input.
>>
>> Presumably, these operators will be added to R anyway, and (almost)
>> no one will listen to me.
>>
>> So, I would like to make one suggestion:
>> Is it possible for these operators to *not* be named:
>> The R Pipe
>> The S Pipe
>> Or anything with a similar meaning.
>>
>> Maybe tidy pipe, or something else that links it to its proponents?
>>
>> ______________________________________________
>> R-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
______________________________________________
R-devel using r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Scanned by McAfee and confirmed virus-free.
Find out more here: https://bit.ly/2zCJMrO
More information about the R-devel
mailing list