回复 第10楼 的 renkun-ken：嗯 我理解并且同意你的观点 用%>>%配合.确实能带来便利和减少麻烦 刚才用了下 代码也直观许多 我的意思是可以试着把这种根据参数分离操作的思路也即这个操作符函数直接folk并提交到dplyr或magrittr去 作者接受不接受是另一回事 至少开源的出发点就是集思广益共同参与嘛
最近写的一个package: pipeR实现两种pipeline operator
回复 第11楼 的 young4u：嗯确实，直接改已有的东西肯定是更好的。不过这里可能需要考虑向前兼容的问题，而且如果看到magrittr和pipeR的代码可以发现前者为了处理上面说的问题进行了许多判断（overhead很大），后者代码非常简单（不到20行），如果PR被接受那么意味着magrittr大部分代码就没了，一些「解决了本不应存在的问题」的feature也没了，对于包本身和兼容性的伤害比较大。如果说magrittr的理念是「更多的feature，统一的符号」，那么pipeR的理念是「更简单的feature，更好的一致性，更独立的功能和符号」，那么两者的设计就有很大的不同了，有点像RJSONIO和jsonlite的区别。
回复 第12楼 的 renkun-ken：那我就明白了 至少跟magrittr是很难合并了 不过我看dplyr里的chain.R好像也是比较简短的 其实一开始就是看到pipeR源代码这么简洁才来发帖一问的 心说直接写在自己.Rprofile里就可以了嘛[s:11]
顺便你的博客写得很好 受益匪浅
回复 第13楼 的 young4u：谢谢，请多指教！
一个点可能引起混淆的话，那用两个点呗，反正..在R里面是合法的变量名，看起来好像也不是太糟糕：
data %>>% lm(y ~ ., data = ..)R的这些语法上的魔法玩起来容易上瘾：）
回复 第15楼 的 谢益辉：前面也想过，不然两种都兼容也行，想用哪个用哪个，两个都有定义如何？函数里面加一句 .. <- . 即可。
回复 第12楼 的 renkun-ken：
分而治之。选择权由用户自行选择使用哪个函数（或操作符），而不是选择函数的哪个参数。不过可能需要在detail里简单的比较性的说明一下与其他类似功能函数的异同。
一个旧帖子讨论过类似的解决方法：
http://cos.name/cn/topic/106785
pipeR v0.2 发布了~
1. 新增 lambda piping %|>% （issue #7）
可以用 (x -> f(x)) 这种形式来表示一个 lambda expression。
<br />
mtcars %|>%<br />
(df -> lm(mpg ~ ., data=df))<br />
2. 取消了 %>>% 直接调用裸函数的功能（issue #8）
不再允许
<br />
rnorm(100,10,1) %>>% log %>>% diff<br />
只允许
<br />
rnorm(100,10,1) %>% log %>% diff<br />
回复 第19楼 的 renkun-ken：
赞！那篇介绍文需要更新一下吗？如果需要你可以修改后邮件给我们。
赞一个！R里面也直接使用了管道符，“军刀”级别的包啊！
吐槽一下：
github里的这段示例代码里的最后一句，我觉得可以换一个值来返回，这样看着更清晰[s:11]
<br />
mtcars %|>%<br />
(df -> lm(mpg ~ ., data=df)) %>%<br />
summary %>>%<br />
.$r.squared<br />
回复 第20楼 的 Ihavenothing：我稍作更新然后发给你，谢谢！
回复 第1楼 的 renkun-ken：
请教，为什么我执行第一段的范例代码没问题，而执行下面这段代码报错呢？
<br />
rnorm(10000,mean=10,sd=1) %>>%<br />
sample(.,size=length(.)*0.2,replace=FALSE) %>>%<br />
log %>>%<br />
diff %>>%<br />
plot(.,col="red",type="l",main=sprintf("length: %d",length(.)))<br />
错误提示为：
[data]错误于curve(expr = x, from = from, to = to, xlim = xlim, ylab = ylab, :
'expr' did not evaluate to an object of length 'n'
[/data]
运行环境是32位的ubuntu12.04LTS+R3.1.0+RStudio 0.98.501
=========
刚才把代码修改了一下，能运行了。。。
<br />
rnorm(10000,mean=10,sd=1) %>>%<br />
sample(.,size=length(.)*0.2,replace=FALSE) %>>%<br />
abs(.) %>>%<br />
log(.) %>>%<br />
diff(.) %>>%<br />
# length(.)<br />
plot(.,col="red",type="l",main=sprintf("length: %d",length(.)))<br />
是有bug还是个例？
</p>
回复 第23楼 的 tjt2008：抱歉，pipeR v0.1版本中的%>>%仍然支持naked function call，也就是类似 rnorm(100) %>>% log。但是v0.2版本中为了使得三种符号（%>%，%>>%，%|>%）功能上保持独立性，于是%>>%不再支持这样的使用方式，而建议用%>%来实现，其中的设计原则是
1. %>% 只管把前面的结果输送到下一个「函数」的第一个参数（因此后面可以是plot或者plot(col="red")）
2. %>>% 只管把前面的结果输送到下一个「表达式」中的.符号中（因此后面可以是一个函数表达式plot(.)，或者plot(.,col="red"），或者是.$a
3. %|>% 只管把前面的结果根据下面指定的 lambda expression 来输送并且计算，因此后面必须是 (符号x -> 关于符号x的表达式) ，例如 (a -> plot(a,col="red")) 这样，前面的结果就放在符号a中，然后计算plot(a,col="red")。如果a是个data.frame或者list，那么也可以是 (a -> a$xyz) 来提取 a中的元素。
上面的设计原则就要求三个符号的功能很清晰，几乎没有重叠，因此使用时需要弄清楚自己在用什么形式的piping，据此来选择使用的符号。不把这三个符号整合成一个的原因在最前面应该已经说明白了。
回复 第24楼 的 renkun-ken：多谢作者耐心解答，我是看了cos首页介绍进来的（话说，首页上的推荐文字没有更新。。。或者是pipeR包更新太快了[s:11]），没注意看到前面的帖子，已经搞明白了.
使用%|>%的时候，没注意到有个细节，后面跟的必须带括号，同时，那个箭头是右箭头[s:15]
看文档不仔细。。。折腾了半小时。。。
回复 第25楼 的 tjt2008：最近会抽出时间直接用中文写一个更系统的v0.2的介绍提供给大家。由于目前pipeR还是在devel阶段并且使用者还很少，因此还不会很顾及扩展包的向前兼容性，主要是按照前面讲的原则来设计的，后面会逐渐锁定特性并且保持向前兼容性。
不错不错 现在用的是dplyr
有空好好研究一下~