moodymudskipper / inops

Infix Operators for Detection, Subsetting and Replacement
GNU General Public License v3.0
40 stars 0 forks source link

support functions/formulas or not #5

Closed moodymudskipper closed 5 years ago

moodymudskipper commented 5 years ago

@KKPMW said:

The only thing I am a bit unsure about is the formula notation. Like the stop thing can probably be written as stopifnot(any(vec >= 1000)). And <- seems like an assignment operator, so a bit weird to assign a stop. On the other hand multiplying all the found matching entries by some constant (or applying any other function to it) is very convenient. I am just wondering if we could do something like x %f==% 2 <- list('', 0.7) instead. Thou the long form is x[x==2] <- x[x==2]0.7 Which almost looks nicer...

moodymudskipper commented 5 years ago

I agree that my example using stop() might not be so useful, but x == 2 <- ~ . * 0.7 seems readable enough to me.

Your counter proposal is hard to implement because we might genuinely want to assign a list.

My proposal has weaker assumptions as it just assumes that you would rarely want to assign a function or a formula to a list element using our assignment functions.

If you think it's confusing we can drop the feature though, and see later if we miss it.

karoliskoncevicius commented 5 years ago

I agree with you about the list - we might want to assign a list, so it fails in the general case, we can discard that.

I think we also have to keep in mind the possible benefit about the shorter notations. For example, would someone be persuaded to use the package so that they can do this:

x == 2 <- ~ . * 0.7

instead of this:

x[x==2] <- x[x==2] * 0.7

Or if we provide the subset alternatives, this seems even better:

(x %subset==% 2) * 0.7

Thou even for subset this standard way seems to be the shortest:

x[x==2] * 0.7

So in my mind the question is - do we gain some advantage from the formula syntax..

You will notice that I am quite conservative when it comes to adding new syntax :) I I think you are more willing to add complex syntax and explore new ideas. Will be interesting to see how this plays out in working on this package.

moodymudskipper commented 5 years ago

Maybe it's better to be more conservative to start with.

I like the feature because to me variable repetition comes with increased cognitive load, and the syntax x < 2 <- 42 is really just to avoid x[x < 2] <- 42 so supporting functions goes a step further in the same direction, plus with a longer variable names you can get something like :

some_df$some_var == 2 <- ~ . * 0.7 # rather than :
some_df$some_var[some_df$some_var == 2] <- some_df$some_var[some_df$some_var == 2] * 0.7

With my package dotdot I would do :

some_df$some_var[some_df$some_var == 2] := .. * 0.7

But I understand we're talking about advanced features before having the basics laid out. I'll remove it for now.

karoliskoncevicius commented 5 years ago

Agreed about some_df$some_var situation.

I am starting to like to formula solution. But maybe we can implement it without ~ and rlang dependency? So just:

some_df$some_var == 2 <- . * 0.7

And we agree to use dot as a placeholder for the x.

moodymudskipper commented 5 years ago

Unfortunately some_df$some_var == 2 <- . * 0.7 is not possible because foo<- functions always evaluate the rhs before even entering the function.

Making the rhs a formula was a way to use NSE here.

moodymudskipper commented 5 years ago

Let's reopen this if we miss it later, and move forward with simpler scope