Should paste0(character(0), c("a","b")) give character(0)?
There is a fair bit of code that assumes that paste("X",NULL) gives "X" but
c(1,2)+NULL gives numeric(0).
-Bill
On Mon, Dec 6, 2021 at 1:32 PM Duncan Murdoch <murdoch.dun...@gmail.com>
wrote:
> On 06/12/2021 4:21 p.m., Avraham Adler wrote:
> > Gabe, I agree that missingness is important to factor in. To somewhat
> abuse
> > the terminology, NA is often used to represent missingness. Perhaps
> > concatenating character something with character something missing should
> > result in the original character?
>
> I think that's a bad idea. If you wanted to represent an empty string,
> you should use "" or NULL, not NA.
>
> I'd agree with Gabe, paste0("abc", NA) shouldn't give "abcNA", it should
> give NA.
>
> Duncan Murdoch
>
> >
> > Avi
> >
> > On Mon, Dec 6, 2021 at 3:35 PM Gabriel Becker <gabembec...@gmail.com>
> wrote:
> >
> >> Hi All,
> >>
> >> Seeing this and the other thread (and admittedly not having clicked
> through
> >> to the linked r-help thread), I wonder about NAs.
> >>
> >> Should NA <concat> "hi there" not result in NA_character_? This is not
> >> what any of the paste functions do, but in my opinoin, NA +
> <non_na_value>
> >> seems like it should be NA (not "NA"), particularly if we are talking
> >> about `+` overloading, but potentially even in the case of a distinct
> >> concatenation operator?
> >>
> >> I guess what I'm saying is that in my head missingness propagation rules
> >> should take priority in such an operator (ie NA + <anything> should
> >> *always * be NA).
> >>
> >> Is that something others disagree with, or has it just not come up yet
> in
> >> (the parts I have read) of this discussion?
> >>
> >> Best,
> >> ~G
> >>
> >> On Mon, Dec 6, 2021 at 10:03 AM Radford Neal <radf...@cs.toronto.edu>
> >> wrote:
> >>
> >>>>> In pqR (see pqR-project.org), I have implemented ! and !! as binary
> >>>>> string concatenation operators, equivalent to paste0 and paste,
> >>>>> respectively.
> >>>>>
> >>>>> For instance,
> >>>>>
> >>>>> > "hello" ! "world"
> >>>>> [1] "helloworld"
> >>>>> > "hello" !! "world"
> >>>>> [1] "hello world"
> >>>>> > "hello" !! 1:4
> >>>>> [1] "hello 1" "hello 2" "hello 3" "hello 4"
> >>>>
> >>>> I'm curious about the details:
> >>>>
> >>>> Would `1 ! 2` convert both to strings?
> >>>
> >>> They're equivalent to paste0 and paste, so 1 ! 2 produces "12", just
> >>> like paste0(1,2) does. Of course, they wouldn't have to be exactly
> >>> equivalent to paste0 and paste - one could impose stricter
> >>> requirements if that seemed better for error detection. Off hand,
> >>> though, I think automatically converting is more in keeping with the
> >>> rest of R. Explicitly converting with as.character could be tedious.
> >>>
> >>> I suppose disallowing logical arguments might make sense to guard
> >>> against typos where ! was meant to be the unary-not operator, but
> >>> ended up being a binary operator, after some sort of typo. I doubt
> >>> that this would be a common error, though.
> >>>
> >>> (Note that there's no ambiguity when there are no typos, except that
> >>> when negation is involved a space may be needed - so, for example,
> >>> "x" ! !TRUE is "xFALSE", but "x"!!TRUE is "x TRUE". Existing uses of
> >>> double negation are still fine - eg, a <- !!TRUE still sets a to TRUE.
> >>> Parsing of operators is greedy, so "x"!!!TRUE is "x FALSE", not
> "xTRUE".)
> >>>
> >>>> Where does the binary ! fit in the operator priority? E.g. how is
> >>>>
> >>>> a ! b > c
> >>>>
> >>>> parsed?
> >>>
> >>> As (a ! b) > c.
> >>>
> >>> Their precedence is between that of + and - and that of < and >.
> >>> So "x" ! 1+2 evalates to "x3" and "x" ! 1+2 < "x4" is TRUE.
> >>>
> >>> (Actually, pqR also has a .. operator that fixes the problems with
> >>> generating sequences with the : operator, and it has precedence lower
> >>> than + and - and higher than ! and !!, but that's not relevant if you
> >>> don't have the .. operator.)
> >>>
> >>> Radford Neal
> >>>
> >>> ______________________________________________
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> ______________________________________________
> >> 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
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
