Bad choice of words I'm afraid. What I'm ultimately pushing for is a feature request. To allow string concatenation with '+' by default. Sure I can write my own string addition function (like the example I posted previously) but I use it so often that I end up putting it in every script I write. It is ultimately a matter of readability and syntactic sugar I guess. As an example, I work in the bioinformatics domain and write R scripts for pipelines with calls to various programs that require a lot of parameters to be set/varied. Seeing "paste" everywhere detracts from reading the code (in my opinion). This may not be a very strong argument, but to give a bit more objective reason, I claim its more readable/intuitive because other big languages have also picked up this convention (C++, java, javascript, python, etc.). Josh Bradley Graduate Student University of Maryland On Tue, Jun 16, 2015 at 11:00 PM, Gabriel Becker <gmbecker at ucdavis.edu> wrote:> > On Jun 16, 2015 3:44 PM, "Joshua Bradley" <jgbradley1 at gmail.com> wrote: > > > > Hi, first time poster here. During my time using R, I have always found > > string concatenation to be (what I feel is) unnecessarily complicated by > > requiring the use of the paste() or similar commands. > > I don't follow. In what sense is paste complicated to use? Not in the > sense of it's actual behavior, since what you propose below has identical > behavior. So is your objection simply the number of characters one must > type? > > I would argue that having a separate verb makes code much more readable, > particularly at a quick glance. I know a character will come out of paste > no matter what goes in. That is not without value from a code maintenance > perspective. IMHO. > > ~G > > > > > > > When searching for how to concatenate strings in R, several top search > > results show answers that say to write your own function or override the > > '+' operator. > > > > Sample code like the following from this > > < > http://stackoverflow.com/questions/4730551/making-a-string-concatenation-operator-in-r > > > > page > > > > "+" = function(x,y) { > > if(is.character(x) & is.character(y)) { > > return(paste(x , y, sep="")) > > } else { > > .Primitive("+")(x,y) > > }} > > > > > > > > An old (2005) post > > <https://stat.ethz.ch/pipermail/r-help/2005-February/066709.html> on > r-help > > mentioned possible performance reasons as to why this type of string > > concatenation is not supported out of the box but did not go into detail. > > Can someone explain why such a basic task as this must be handled by > > paste() instead of just using the '+' operator directly? Would > performance > > degrade much today if the '+' form of string concatenation were added > into > > R by default? > > > > > > > > Josh Bradley > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
> ... adding the ability to concat > strings with '+' would be a relatively simple addition (no pun intended)to> the code base I believe. With a lot of other languages supporting thiskind> of concatenation, this is what surprised me most when first learning R.Wow! R has a lot of surprising features and I would have thought this would be quite a way down the list. How would this new '+' deal with factors, as paste does or as the current '+' does? Would number+string and string+number cause errors (as in current '+' in R and python) or coerce both to strings (as in current R:paste and in perl's '+'). Having '+' work on all types of data can let improperly imported data get further into the system before triggering an error. I see lots of errors reported on this list that are due to read.table interpreting text as character strings instead of the numbers that the user expected. Detecting that error as early as possible is good. Bill Dunlap TIBCO Software wdunlap tibco.com On Tue, Jun 16, 2015 at 10:25 PM, Joshua Bradley <jgbradley1 at gmail.com> wrote:> Bad choice of words I'm afraid. What I'm ultimately pushing for is a > feature request. To allow string concatenation with '+' by default. Sure I > can write my own string addition function (like the example I posted > previously) but I use it so often that I end up putting it in every script > I write. > > It is ultimately a matter of readability and syntactic sugar I guess. As an > example, I work in the bioinformatics domain and write R scripts for > pipelines with calls to various programs that require a lot of parameters > to be set/varied. Seeing "paste" everywhere detracts from reading the code > (in my opinion). > > This may not be a very strong argument, but to give a bit more objective > reason, I claim its more readable/intuitive because other big languages > have also picked up this convention (C++, java, javascript, python, etc.). > > > Josh Bradley > Graduate Student > University of Maryland > > On Tue, Jun 16, 2015 at 11:00 PM, Gabriel Becker <gmbecker at ucdavis.edu> > wrote: > > > > > On Jun 16, 2015 3:44 PM, "Joshua Bradley" <jgbradley1 at gmail.com> wrote: > > > > > > Hi, first time poster here. During my time using R, I have always found > > > string concatenation to be (what I feel is) unnecessarily complicated > by > > > requiring the use of the paste() or similar commands. > > > > I don't follow. In what sense is paste complicated to use? Not in the > > sense of it's actual behavior, since what you propose below has identical > > behavior. So is your objection simply the number of characters one must > > type? > > > > I would argue that having a separate verb makes code much more readable, > > particularly at a quick glance. I know a character will come out of paste > > no matter what goes in. That is not without value from a code maintenance > > perspective. IMHO. > > > > ~G > > > > > > > > > > > When searching for how to concatenate strings in R, several top search > > > results show answers that say to write your own function or override > the > > > '+' operator. > > > > > > Sample code like the following from this > > > < > > > http://stackoverflow.com/questions/4730551/making-a-string-concatenation-operator-in-r > > > > > > page > > > > > > "+" = function(x,y) { > > > if(is.character(x) & is.character(y)) { > > > return(paste(x , y, sep="")) > > > } else { > > > .Primitive("+")(x,y) > > > }} > > > > > > > > > > > > An old (2005) post > > > <https://stat.ethz.ch/pipermail/r-help/2005-February/066709.html> on > > r-help > > > mentioned possible performance reasons as to why this type of string > > > concatenation is not supported out of the box but did not go into > detail. > > > Can someone explain why such a basic task as this must be handled by > > > paste() instead of just using the '+' operator directly? Would > > performance > > > degrade much today if the '+' form of string concatenation were added > > into > > > R by default? > > > > > > > > > > > > Josh Bradley > > > > > > [[alternative HTML version deleted]] > > > > > > ______________________________________________ > > > R-devel at r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
On Wed, Jun 17, 2015 at 12:45 PM, William Dunlap <wdunlap at tibco.com> wrote:>> ... adding the ability to concat >> strings with '+' would be a relatively simple addition (no pun intended) > to >> the code base I believe. With a lot of other languages supporting this > kind >> of concatenation, this is what surprised me most when first learning R. > > Wow! R has a lot of surprising features and I would have thought > this would be quite a way down the list.Well, it is hard to guess what users and people in general find surprising. As '+' is used for string concatenation in essentially all major scripting (and many other) languages, personally I am not surprised that this is surprising for people. :)> How would this new '+' deal with factors, as paste does or as the current > '+' > does?The same as before. It would not change the behavior for other classes, only basic characters.> Would number+string and string+number cause errors (as in current > '+' in R and python) or coerce both to strings (as in current R:paste and > in perl's '+').Would cause errors, exactly as it does right now.> Having '+' work on all types of data can let improperly imported data > get further into the system before triggering an error.Nobody is asking for this. Only characters, not all types of data.> I see lots of > errors > reported on this list that are due to read.table interpreting text as > character > strings instead of the numbers that the user expected. Detecting that > error as early as possible is good.Isn't that a problem with read.table then? Detecting it there would be the earliest possible, no? Gabor [...]
On Wed, Jun 17, 2015 at 1:25 AM, Joshua Bradley <jgbradley1 at gmail.com> wrote:> ?I work in the bioinformatics domain and write R scripts for > pipelines with calls to various programs that require a lot of parameters > to be set/varied. Seeing "paste" everywhere detracts from reading the code > (in my opinion).In that case, why don't you just write a personal package with that functionality and automatically load it? Avi
> How would this new '+' deal with factors, as paste does or as the current'+'> does? Would number+string and string+number cause errors (as in current > '+' in R and python) or coerce both to strings (as in current R:paste andin perl's '+'). I had posted this sample code previously to demonstrate how string concatenation could be implemented "+" = function(x,y) { if(is.character(x) & is.character(y)) { return(paste0(x , y)) } else { .Primitive("+")(x,y) }} so it would only happen if both objects were characters, otherwise you should expect the same behavior as before with all other classes. This would be backwards compatible as well since string+string was never supported before and therefore no one would have previously working code that could break. Josh Bradley [[alternative HTML version deleted]]