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

Reply via email to