package scope

[moodymudskipper]

@KKPMW said :

What I would like to see in this package:

in[] in{} in(), etc

out[] (or !in[]) variants

variants that work with tables (so replace values that occur some n of times)

variants that help with "cut" so maybe x %#cut% 5 <- letters[5] would cut x into 5 intervals and name them A-E.

[moodymudskipper]

We agreed now that the scope is detect (logical output), subset, replace, matches according to equality, inequality, intersection with a range or regex, using a decently generalisable syntax to welcome additional operators if necessary.

These operators return the same type of data (or warning/errors) than equality and comparison operators do, when applied on flat atomic vectors, matrices, lists or data frames, with the difference that our right hand sides have different restrictions depending on the operator. They also treat NA as equality and comparison operators do, i.e. they keep them (unlike %in%).

Replacement operators are wrapper around our detection operators and replace and are named as the assignment form of the detection operators ( e.g. %in{}% and %in{}<-%), and assignment forms to equality and comparison operators are defined as well. (==<- etc)

Additional ideas are to design additional infix operators to wrap our detection operators in :

• which() to get numeric indices
• all() or any() to get a logical scalar
• sum() to get a count

But all those are considered out of scope for now as it's not clear if they bring enough value.

[karoliskoncevicius]

I tend to agree they do not bring enough value. From all those other variants, I only imagine the subset one brings value. For other instances simply wrapping the result in appropriate function like:

which(x %in{}% c("a", "b"))

seems to be enough.

Let's drop these which all and sum?

[moodymudskipper]

pinning and closing as I think we're good here!