There are several problems with %+% : - %whatever% should be open for use by the user and if R starts taking them over they won't be
- %+% is ugly - %+% is not consistent with other languages (the C-based syntax of R is supposed to leverage off one's knowledge of other languages) Personally I would prefer status quo, + or paste0 to %+% . On 8/26/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 8/26/2006 10:26 AM, John Chambers wrote: > > Well, two comments, in two non-compatible directions. > > > > 1. I have to say that I find the idea of using "+" to paste character > > strings together aesthetically ugly. > > > > IMO, one thing that makes functional object-based languages attractive > > is that the generic function retains a consistent _function_, that is, > > purpose and meaning, of which the methods are implementations. > > > > It escapes me totally why I should think of pasting strings as addition > > in the mathematical or intuitive sense (as Brian points out re > > commutativity, it fails a number of axiomatic properties). And if so, > > what about "-", "*", "/" and so on? The mind boggles. > > Assuming that your "totally" is literally true: > > Strings don't form a commutative group under concatenation, but the > operation is associative, and there's a zero element "". This makes > them a monoid or unitary semigroup. The natural numbers (including > zero) are another example of a monoid under addition. It's not that > weird to have addition defined without negatives. > > Concatenation seems to me to be the most natural interpretation of > addition for strings. > > According to Wikipedia, the "+" operator is used for concatenation in > BASIC, Pascal, Delphi, Javascript, Java, Python, C++ and Ruby. These > are probably the most commonly used modern languages other than C (which > has no concatenation operator) or Fortran (which I just discovered today > uses "//"). > > Other possibilities on the Wikipedia page that don't conflict with > something else in R are: > > Visual Basic and VHDL use the "&" sign. > > Standard SQL, PL/I, and Maple from version 6 uses double pipe signs ("||"). > > OCaml uses "^". > > So it seems to me that defining addition of strings to be concatenation > is a reasonably widespread convention. > > I don't think there are widespread conventions for subtraction, > multiplication or division of strings, so I can't see any argument for > implementing them. > > > Its excuse presumably is to save typing, but I would favor using some > > %thing% operator at the cost of a couple of extra key strokes. > > I think consistency with other common languages is a stronger reason. > Other than that, I'd be perfectly happy with %+%. > > Duncan Murdoch > > > > > > 2. Having said that, it's a reasonable hope that efficiency of > > dispatch will not be a serious problem. There are a bunch of fixes, for > > semantic correctness and efficiency, nearly ready to commit (the > > Bioconductor folks have been doing some valuable testing). These should > > help, and more important perhaps it's fairly easy to see how dispatch in > > this form can be tuned for performance if necessary. > > > > John > > > > Bill Dunlap wrote: > >>>> >> 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="") > >>>> ... > >>>> 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. > >>> > >> Currently doing arithmetic on mixed class data.frames > >> produces useful warnings and errors. E.g., > >> > >> > z <- data.frame(Factor=factor(c("Lo","Med","High")), > >> Char=letters[1:3], > >> Num1=exp(0:2), > >> Num2=(1:3)*pi, > >> stringsAsFactors=FALSE) > >> > z+1 > >> Error in FUN(left, right) : non-numeric argument to binary operator > >> In addition: Warning message: > >> + not meaningful for factors in: Ops.factor(left, right) > >> > z[,-2] + 1 > >> Factor Num1 Num2 > >> 1 NA 2.000000 4.141593 > >> 2 NA 3.718282 7.283185 > >> 3 NA 8.389056 10.424778 > >> Warning message: > >> + not meaningful for factors in: Ops.factor(left, right) > >> > >> If we made + do paste(sep="") for character+number then > >> we would lose the messages and let garbage flow further > >> down the pipe. > >> > >> Should factor data be treated as character data in this > >> case (e.g., pasting to the levels)? That would be weird, > >> but many users confound character and factor data when > >> they are buried in data.frames. > >> > >> ---------------------------------------------------------------------------- > >> Bill Dunlap > >> Insightful Corporation > >> bill at insightful dot com > >> 360-428-8146 > >> > >> "All statements in this message represent the opinions of the author and > >> do > >> not necessarily reflect Insightful Corporation policy or position." > >> > >> ______________________________________________ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > >> > > > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel