On 8/25/2006 4:55 PM, Martin Maechler wrote: >>>>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]> >>>>>> on Fri, 25 Aug 2006 13:18:42 -0400 writes: > > Duncan> On 8/25/2006 12:31 PM, Martin Maechler wrote: > >> This thread remains me of an old recurring (last May!) > >> theme which maybe fits well to Friday late afternoon... > >> > >> There have been propositions to make "+" work in S (and > >> R) like in some other languages, namely for character > >> (vectors), > >> > >> a + b := paste(a,b, sep="") > >> > >> IIRC, when this theme came up last, the one argument > >> against it was the penalty of method dispatch that we > >> were not willing to pay for something as fundamentally > >> speed-important as "+" -- which is a .Primitive in R > >> exactly for that reason of efficiency. > >> > >> But then, we actually do dispatch for "+" -- internally > >> in C code via DispatchGroup() --- but only if we need, so > >> not when usual numeric/complex arguments are used. > >> > >> I think - but may be wrong - it should be possible to > >> also check very fast for two "character" arguments and in > >> that case do a fast version of paste(a, b, sep=""). > > Duncan> But for consistency shouldn't this work if only one > Duncan> of the args is character, coercing the other to > Duncan> character? E.g. we have > > >> "2" > 10 > Duncan> [1] TRUE > > yes. But see also below > > >> When this last came up (in May), Brian said that about > >> the fact that you could not just simply define > >> "+.character" > >> > >>>> I would think that the intention was also to positively > >>>> discourage messing with the basics of R, as if you were > >>>> able to do this erroneous uses would likely not get > >>>> caught. > >> ( > >> https://stat.ethz.ch/pipermail/r-help/2006-May/104751.html > >> ) and subsequently > >> (https://stat.ethz.ch/pipermail/r-help/2006-May/104754.html) > >> gave an example for this > >> > >>>> 2 + x, for example, where x is not numeric. > > Duncan> This is a valid concern, but I think the clarity > Duncan> obtained by coding paste operations using + is worth > Duncan> it. > > Duncan> For example, the first instance of paste(a, b, > Duncan> sep="") I see in the source is > > Duncan> is.ALL(structure(1:7, names = paste("a",1:7,sep=""))) > > Duncan> in base/demo/is.things.R > > Duncan> which I find clearer as > > Duncan> is.ALL(structure(1:7, names = "a" + 1:7)) > > > Duncan> But then I'm used to using + for strings from > Duncan> Borland's Pascal extensions; to a C-speaker the > Duncan> meaning may not be so obvious. > > yes. I think however if we keep speed and clarity and catching > user errors all in mind, it would be enough - and better - to > only dispatch to paste(.,.) when both arguments are character > (vectors), i.e., the above case needed > "a" + as.character(1:7) or "a" + paste(1:7) or "a" + format(1:7) > which after all is really more clearer, even more for cases of > "1" + 2 which I'd rather want keeping to give errors. > > If Char + Num should work like above, then also > Num + Char should (since after all, "+" should be commutative > apart from floating point precision issues). > > and so the internal C code gets a bit more complicated and slightly > slower.. something we had in mind we should strongly avoid...
I doubt that it would be measurably slower, but I agree that requiring both args to be Char could be done in fewer operations than just requiring one. However, I think the consistency argument is stronger. We have a rule that operations on mixed types promote the more restrictive type to the less restrictive one, and I don't think we should handle this case differently. So I'd say we should allow all of Char + Num, Num + Char, and Char + Char, or, if this costs too much at evaluation time, we shouldn't allow any of them. Duncan Murdoch > > Martin > > >> I wonder however, if we do this in C, and basically only > >> go into the paste-branch when both arguments are > >> characters, if we wouldn't get to a nice useful solution > >> without a noticable performance penalty. > >> > >> This would also solve my other slight related uneasyness > >> : Many times in the past, when using paste(..., sep='') > >> in function definitions I had wanted this (empty sep) to > >> be the default and to have an easier, more readable way > >> to achieve the same. > >> > >> But then these all are just musings at the end of the > >> week... > >> > >> Martin Maechler, ETH Zurich > >> > >> ______________________________________________ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > Duncan> ______________________________________________ > Duncan> R-devel@r-project.org mailing list > Duncan> https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel