From jgbradley1 at gmail.com  Wed Jun 17 20:24:08 2015
From: jgbradley1 at gmail.com (Joshua Bradley)
Date: Wed, 17 Jun 2015 14:24:08 -0400
Subject: [Rd] Improving string concatenation
In-Reply-To: <CAF8bMcZ1pRVVN2ZhDZ1EEq_vMN_1WzNvyw1e24cE=TDa=m+mmQ@mail.gmail.com>
References: <CAKShX4A5bVtxVAG+01QjNH0=LaVr6MH48xXs-OtbQQ2247cc_g@mail.gmail.com>
	<CADwqtCMPAbayj7TENRPtPSXjyFi7wjWfdW9qke7n+PExdwkpbw@mail.gmail.com>
	<CAKShX4D-LHgmh5cO2xxnLypzSgCWLDEnHopfE00MwbRFpRvmLg@mail.gmail.com>
	<CAF8bMcZ1pRVVN2ZhDZ1EEq_vMN_1WzNvyw1e24cE=TDa=m+mmQ@mail.gmail.com>
Message-ID: <CAKShX4ACOn7Hnzo_pC+Ar9-r-8Gh3w4R77s7inNLyYto7Qoytg@mail.gmail.com>

> 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 '+').


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]]



[Rd] Improving string concatenation
Joshua Bradley