Re: [Rd] Support for user defined unary functions

On 17 March 2017 at 18:02, Jim Hester wrote: | The user defined pipe operator (%>%), now used by > 300 packages, is | an example that giving package authors the power to experiment can | produce beneficial ideas for the community. Well, you can read that two ways. To me it seems over 9700

Re: [Rd] Support for user defined unary functions

I can see that allowing a user-defined unary prefix operator can be useful. We want to make sure its precedence and associative behavior are convenient for a variety of envisioned uses, as we won't get a chance to change them after the language construct is introduced. An example of precedence

Re: [Rd] Support for user defined unary functions

The unquoting discussion is IMHO separate from this proposal and as you noted probably better served by a native operator with different precedence. I think the main benefit to providing user defined prefix operators is it allows package authors to experiment with operator ideas and gauge

Re: [Rd] Support for user defined unary functions

OK. I am more concerned now with semantics than the syntax. Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, Mar 17, 2017 at 1:09 PM, Gabriel Becker wrote: > Bill, > > Right. My example was the functional form for clarity. > > There is a desire for a unary-operator

Re: [Rd] Support for user defined unary functions

Bill, Right. My example was the functional form for clarity. There is a desire for a unary-operator form. (rlang's !! and !!! operators described in the comments in the file I linked to). I can't really make that argument because I'm not one of the people who wanted that. You'd have to talk to

Re: [Rd] Support for user defined unary functions

Your example x = 5 exp = parse(text="f(uq(x)) + y +z") # expression: f(uq(x)) +y + z do_unquote(expr) # -> the language object f(5) + y + z could be done with the following wrapper for bquote my_do_unquote <- function(language, envir = parent.frame()) { if

Re: [Rd] Support for user defined unary functions

William, Unbeknownst to me when I sent this, Jonathon Carrol started a specific thread about unquoting and a proposal for supporting it at the language level, which I think is a better place to discuss unquoting specifically. That said, the basics as I understand them in the context of

Re: [Rd] Support for user defined unary functions

>After off list discussions with Jonathan Carrol and with >Michael Lawrence I think it's doable, unambiguous, >and even imo pretty intuitive for an "unquote" operator. For those of us who are not CS/Lisp mavens, what is an "unquote" operator? Can you expression quoting and unquoting in R syntax

Re: [Rd] Support for user defined unary functions

Jim, One more note about precedence. It prevents a solution like the one you proposed from solving all of the problems you cited. By my reckoning, a "What comes next is for NSE" unary operator needs an extremely low precedence, because it needs to greedily grab "everything" (or a large amount)

Re: [Rd] Support for user defined unary functions

I agree there is no reason they _need_ to be the same precedence, but I think SPECIALS are already have the proper precedence for both unary and binary calls. Namely higher than all the binary operators (except for `:`), but lower than the other unary operators. Even if we gave unary specials

Re: [Rd] Support for user defined unary functions

This works the same way as `?` is defined in R code, and `-`, `+` (defined in C) do now, you define one function that handles calls with both unary and binary arguments. quote(a %f% %f% b) #> a %f% (`%f%`(b)) `%f%` <- function(a, b) if (missing(b)) { force(a); cat("unary\n") } else {

Re: [Rd] Support for user defined unary functions

I don't have a positive or negative opinion on this yet, but I do have a question. If I define both unary and binary operators with the same name (in different frames, presumably), what would happen? Is "a %chr% b" a syntax error if unary %chr% is found first? If both might be found, does

Re: [Rd] Support for user defined unary functions

I am biased against introducing new syntax, but if one is experimenting with it one should make sure the precedence feels right. I think the unary and binary minus-sign operators have different precedences so I see no a priori reason to make the unary and binary %xxx% operators to be the same.

Re: [Rd] Support for user defined unary functions

I guess this would establish a separate "namespace" of symbolic prefix operators, %*% being an example in the infix case. So you could have stuff like %?%, but for non-symbolic (spelled out stuff like %foo%), it's hard to see the advantage vs. foo(x). Those examples you mention should probably be

Re: [Rd] Support for user defined unary functions

I used the `function(x)` form to explicitly show the function was being called with only one argument, clearly performance implications are not relevant for these examples. I think of this mainly as a gap in the tooling we provide users and package authors. R has native prefix `+1`, functional

Re: [Rd] Support for user defined unary functions

> Jim Hester > on Thu, 16 Mar 2017 12:31:56 -0400 writes: > Gabe, > The unary functions have the same precedence as normal SPECIALS > (although the new unary forms take precedence over binary SPECIALS). > So they are lower precedence than

Re: [Rd] Support for user defined unary functions

Gabe, The unary functions have the same precedence as normal SPECIALS (although the new unary forms take precedence over binary SPECIALS). So they are lower precedence than unary + and -. Yes, both of your examples are valid with this patch, here are the results and quoted forms to see the

Re: [Rd] Support for user defined unary functions

Jim, This seems cool. Thanks for proposing it. To be concrete, he user-defined unary operations would be of the same precedence (or just slightly below?) built-in unary ones? So "100" %identical% %chr% 100 would work and return TRUE under your patch? And with %num% <- as.numeric, then 1 + -

[Rd] Support for user defined unary functions

R has long supported user defined binary (infix) functions, defined with `%fun%`. A one line change [1] to R's grammar allows users to define unary (prefix) functions in the same manner. `%chr%` <- function(x) as.character(x) `%identical%` <- function(x, y) identical(x, y) %chr% 100