search

moodymudskipper / tb

IN ~PROGRESS my own take on `[.data.frame`
0 stars 0 forks source link

splicing and dbl tilde issues #31

Open moodymudskipper opened 4 years ago

moodymudskipper commented 4 years ago

Because we try to splice first we get issues when using ~~

for instance mytb[order(+log(~~.data[1:2])),]

To be robust, and also more efficient, we should do all this parse magic at once.

We have another issue here, which is that by doing this early we evaluate .data before it's computed.

splicing will need to be taken seriously with hard tests so we can use it on the results of aggregations and for unpacking too.

moodymudskipper commented 4 years ago

I think the reason why this early splicing is done is just so we can sort out which argment goes where (named arguments etc), but I think we could postulate that + arguments(not ++ args!) will be named anyway and make them fail at the right time if they're not, then we can do all this splicing/evaluation gymnastic at the right time.

Maybe ~~ used in a subcall should still work rowwise for the full argument, that'd be more intuitive.

This might be problematic though when we don't want it rowwise but for a sub map call.

Technicallly foo(~chr~ x, y) could be both type stable AND not rowwise, but that's confusing...

Or !~ for rowwise, to differentiate it more. Or ~rw~

OR another special syntax to protect the outside fun from ~~

Another way of doing rowwise would be a rw(expr) function or rw? expr or rw ~ expr (confusing with along notation!) and then all symbols that are columns will be evaluated in sequence ?