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 packages ignore the pipe operator. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 getting in the way is when you would like to define a matrix-exponentiation operator, %^%. It will have the same precedence as %% so - x %^% 2 will be equivalent to (-x) %^% 2 and not to - (x %^% 2) [A long time ago someone wanted new postfix operators (e.g., bang for factorial). Is that desire still around?] Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, Mar 17, 2017 at 3:02 PM, Jim Hesterwrote: > 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 > community interest. The current situation means any novel unary > semantics either need to co-opt existing unary operators or propose > changes to the R parser, neither of which is ideal for > experimentation. > > 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. > > On Fri, Mar 17, 2017 at 9:46 AM, Gabriel Becker wrote: >> 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) that comes after it. Normal-style unary operators, on the other >> hand, explicitly don't want that. >> >> From what I can see, your patch provides support for the latter but not the >> former. >> >> That said I think there are two issues here. One is can users define unary >> operators. FWIW my opinion on that is roughly neutral to slightly positive. >> The other issue is can we have quasi quotation of the type that Hadley and >> Lionel need in the language. This could be solved without allowing >> user-defined unary specials, and we would probably want it to be, as I doubt >> ~ %!%x + %!%y + z is particularly aesthetically appealing to most (it isn't >> to me). I'd propose coopting unary @ for that myself. 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. >> >> Best, >> ~G >> >> On Fri, Mar 17, 2017 at 5:10 AM, Jim Hester >> wrote: >>> >>> 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 their own precedence I think it would end up in the >>> same place. >>> >>> `%l%` <- function(x) tail(x, n = 1) >>> %l% 1:5 >>> #> [1] 5 >>> %l% -5:-10 >>> #> [1] -10 >>> >>> On Thu, Mar 16, 2017 at 6:57 PM, William Dunlap wrote: >>> > 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. >>> > Bill Dunlap >>> > TIBCO Software >>> > wdunlap tibco.com >>> > >>> > >>> > On Thu, Mar 16, 2017 at 3:18 PM, Michael Lawrence >>> > wrote: >>> >> 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 addressed (eventually) in >>> >> the >>> >> core language, and it looks like people are already able to experiment, >>> >> so >>> >> I'm not sure there's a significant impetus for this change. >>> >> >>> >> Michael >>> >> >>> >> >>> >> On Thu, Mar 16, 2017 at 10:51 AM, Jim Hester >>> >> wrote: >>> >> >>> >>> 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 `f(1)` and infix >>> >>> `1 + 1` operators,
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 community interest. The current situation means any novel unary semantics either need to co-opt existing unary operators or propose changes to the R parser, neither of which is ideal for experimentation. 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. On Fri, Mar 17, 2017 at 9:46 AM, Gabriel Beckerwrote: > 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) that comes after it. Normal-style unary operators, on the other > hand, explicitly don't want that. > > From what I can see, your patch provides support for the latter but not the > former. > > That said I think there are two issues here. One is can users define unary > operators. FWIW my opinion on that is roughly neutral to slightly positive. > The other issue is can we have quasi quotation of the type that Hadley and > Lionel need in the language. This could be solved without allowing > user-defined unary specials, and we would probably want it to be, as I doubt > ~ %!%x + %!%y + z is particularly aesthetically appealing to most (it isn't > to me). I'd propose coopting unary @ for that myself. 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. > > Best, > ~G > > On Fri, Mar 17, 2017 at 5:10 AM, Jim Hester > wrote: >> >> 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 their own precedence I think it would end up in the >> same place. >> >> `%l%` <- function(x) tail(x, n = 1) >> %l% 1:5 >> #> [1] 5 >> %l% -5:-10 >> #> [1] -10 >> >> On Thu, Mar 16, 2017 at 6:57 PM, William Dunlap wrote: >> > 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. >> > Bill Dunlap >> > TIBCO Software >> > wdunlap tibco.com >> > >> > >> > On Thu, Mar 16, 2017 at 3:18 PM, Michael Lawrence >> > wrote: >> >> 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 addressed (eventually) in >> >> the >> >> core language, and it looks like people are already able to experiment, >> >> so >> >> I'm not sure there's a significant impetus for this change. >> >> >> >> Michael >> >> >> >> >> >> On Thu, Mar 16, 2017 at 10:51 AM, Jim Hester >> >> wrote: >> >> >> >>> 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 `f(1)` and infix >> >>> `1 + 1` operators, but we only provide a mechanism to create user >> >>> defined functional and infix operators. >> >>> >> >>> One could also argue that the user defined infix operators are also >> >>> ugly and could be replaced by `f(a, b)` calls as well; beauty is in >> >>> the eye of the beholder. >> >>> >> >>> The unquote example [1] shows one example where this gap in tooling >> >>> caused authors to co-opt existing unary exclamation operator, this >> >>> same gap is part of the reason the formula [2] and question mark [3] >> >>> operators have been used elsewhere in non standard contexts. >> >>> >> >>> If the language provided package authors with a native way to create >> >>> unary operators like it already does for the other operator types >> >>> these machinations would be unnecessary. >> >>> >> >>> [1]:
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 Beckerwrote: > 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 the authors of the rlang package to find out their reasons for > thinking that is important. All I know is that empirically, they seem to > feel that way. There may also be issues with the use of . specifically, > because this is in the "tidyverse" context where piping is common and . is > used for something else there, but again that's conjecture on my part. > > Best, > ~G > > On Fri, Mar 17, 2017 at 12:53 PM, William Dunlap wrote: >> >> 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 (is.expression(language)) { >> # bquote does not go into expressions, only calls >> as.expression(lapply(language, my_do_unquote)) >> } else { >> do.call(bquote, list(language, where=envir)) >> } >>} >> as in >>> x <- 5 >>> exp <- parse(text="f(.(x)) + y +z") # dot is uq for bquote >>> exp >>expression(f(.(x)) + y +z) >>> my_do_unquote(exp) >>expression(f(5) + y + z) >> Or do uq() and do_unquote() do more than that? E.g., would >> uq() carry information about environments? >> >> [I think expressions should map to expressions and calls to calls. >> Otherwise what would we do with multicall expressions?] >> >> We probably need to come up with a better name than 'non-standard >> evaluation' since there are lots of non-standard ways of doing things. >> Bill Dunlap >> TIBCO Software >> wdunlap tibco.com >> >> >> On Fri, Mar 17, 2017 at 12:14 PM, Gabriel Becker >> wrote: >> > 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 >> > non-standard >> > evaluation, unquoting (or perhaps interpolation) is essentially >> > substituting >> > part of an unevaluated expression with its evaluated value inlined. The >> > unquote operator, then, is the way of marking which parts of the >> > expression >> > should be substituted in that way (i.e. interpolated). >> > >> > i.e. if uq() is the unquote "operator" and do_unquote interpolates, then >> > if >> > we have >> > >> > x = 5 >> > >> > exp = parse(text="f(uq(x)) + y +z") # expression: f(uq(x)) +y + z >> > >> > >> > Then do_unquote would give you the expression f(5) + y + z >> > >> > In terms of what it does that the tilde does not, it would give you the >> > ability to partially evaluate the captured formula/expression, without >> > fully >> > doing so. See the roxygen comments in Hadley and Lionel's rlang package >> > here: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R >> > >> > The desired precedence of such a unary operator is not clear to me. The >> > way >> > rlang implements the !! now, it is quite low, so in the examples you see >> > there the ~list(!! x + x) is transformed to ~list(10), not ~list(5+x) as >> > I >> > would have expected. I'm confused by this given what I understand the >> > purpose to be, but that probably just means I'm not the right person to >> > ask. >> > >> > Hope that helps. >> > >> > Best, >> > ~G >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > On Fri, Mar 17, 2017 at 8:55 AM, William Dunlap >> > wrote: >> >> >> >> >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 and show a few examples where is is useful, >> >> intuitive, and fits in to R's functional design? In particular, >> >> what does it give us that the current tilde function does not? >> >> >> >> >> >> Bill Dunlap >> >> TIBCO Software >> >> wdunlap tibco.com >> >> >> >> >> >> On Fri, Mar 17, 2017 at 6:46 AM, Gabriel Becker >> >> wrote: >> >> > 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
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 the authors of the rlang package to find out their reasons for thinking that is important. All I know is that empirically, they seem to feel that way. There may also be issues with the use of . specifically, because this is in the "tidyverse" context where piping is common and . is used for something else there, but again that's conjecture on my part. Best, ~G On Fri, Mar 17, 2017 at 12:53 PM, William Dunlapwrote: > 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 (is.expression(language)) { > # bquote does not go into expressions, only calls > as.expression(lapply(language, my_do_unquote)) > } else { > do.call(bquote, list(language, where=envir)) > } >} > as in >> x <- 5 >> exp <- parse(text="f(.(x)) + y +z") # dot is uq for bquote >> exp >expression(f(.(x)) + y +z) >> my_do_unquote(exp) >expression(f(5) + y + z) > Or do uq() and do_unquote() do more than that? E.g., would > uq() carry information about environments? > > [I think expressions should map to expressions and calls to calls. > Otherwise what would we do with multicall expressions?] > > We probably need to come up with a better name than 'non-standard > evaluation' since there are lots of non-standard ways of doing things. > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > > On Fri, Mar 17, 2017 at 12:14 PM, Gabriel Becker > wrote: > > 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 non-standard > > evaluation, unquoting (or perhaps interpolation) is essentially > substituting > > part of an unevaluated expression with its evaluated value inlined. The > > unquote operator, then, is the way of marking which parts of the > expression > > should be substituted in that way (i.e. interpolated). > > > > i.e. if uq() is the unquote "operator" and do_unquote interpolates, then > if > > we have > > > > x = 5 > > > > exp = parse(text="f(uq(x)) + y +z") # expression: f(uq(x)) +y + z > > > > > > Then do_unquote would give you the expression f(5) + y + z > > > > In terms of what it does that the tilde does not, it would give you the > > ability to partially evaluate the captured formula/expression, without > fully > > doing so. See the roxygen comments in Hadley and Lionel's rlang package > > here: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R > > > > The desired precedence of such a unary operator is not clear to me. The > way > > rlang implements the !! now, it is quite low, so in the examples you see > > there the ~list(!! x + x) is transformed to ~list(10), not ~list(5+x) as > I > > would have expected. I'm confused by this given what I understand the > > purpose to be, but that probably just means I'm not the right person to > ask. > > > > Hope that helps. > > > > Best, > > ~G > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 17, 2017 at 8:55 AM, William Dunlap > wrote: > >> > >> >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 and show a few examples where is is useful, > >> intuitive, and fits in to R's functional design? In particular, > >> what does it give us that the current tilde function does not? > >> > >> > >> Bill Dunlap > >> TIBCO Software > >> wdunlap tibco.com > >> > >> > >> On Fri, Mar 17, 2017 at 6:46 AM, Gabriel Becker > >> wrote: > >> > 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) that comes after it. Normal-style unary operators, on the > other > >> > hand, explicitly don't want that. > >> > > >> > From what I can see, your patch provides support for the latter but > not > >> > the > >> > former. > >>
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 (is.expression(language)) { # bquote does not go into expressions, only calls as.expression(lapply(language, my_do_unquote)) } else { do.call(bquote, list(language, where=envir)) } } as in > x <- 5 > exp <- parse(text="f(.(x)) + y +z") # dot is uq for bquote > exp expression(f(.(x)) + y +z) > my_do_unquote(exp) expression(f(5) + y + z) Or do uq() and do_unquote() do more than that? E.g., would uq() carry information about environments? [I think expressions should map to expressions and calls to calls. Otherwise what would we do with multicall expressions?] We probably need to come up with a better name than 'non-standard evaluation' since there are lots of non-standard ways of doing things. Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, Mar 17, 2017 at 12:14 PM, Gabriel Beckerwrote: > 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 non-standard > evaluation, unquoting (or perhaps interpolation) is essentially substituting > part of an unevaluated expression with its evaluated value inlined. The > unquote operator, then, is the way of marking which parts of the expression > should be substituted in that way (i.e. interpolated). > > i.e. if uq() is the unquote "operator" and do_unquote interpolates, then if > we have > > x = 5 > > exp = parse(text="f(uq(x)) + y +z") # expression: f(uq(x)) +y + z > > > Then do_unquote would give you the expression f(5) + y + z > > In terms of what it does that the tilde does not, it would give you the > ability to partially evaluate the captured formula/expression, without fully > doing so. See the roxygen comments in Hadley and Lionel's rlang package > here: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R > > The desired precedence of such a unary operator is not clear to me. The way > rlang implements the !! now, it is quite low, so in the examples you see > there the ~list(!! x + x) is transformed to ~list(10), not ~list(5+x) as I > would have expected. I'm confused by this given what I understand the > purpose to be, but that probably just means I'm not the right person to ask. > > Hope that helps. > > Best, > ~G > > > > > > > > > > > On Fri, Mar 17, 2017 at 8:55 AM, William Dunlap wrote: >> >> >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 and show a few examples where is is useful, >> intuitive, and fits in to R's functional design? In particular, >> what does it give us that the current tilde function does not? >> >> >> Bill Dunlap >> TIBCO Software >> wdunlap tibco.com >> >> >> On Fri, Mar 17, 2017 at 6:46 AM, Gabriel Becker >> wrote: >> > 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) that comes after it. Normal-style unary operators, on the other >> > hand, explicitly don't want that. >> > >> > From what I can see, your patch provides support for the latter but not >> > the >> > former. >> > >> > That said I think there are two issues here. One is can users define >> > unary >> > operators. FWIW my opinion on that is roughly neutral to slightly >> > positive. >> > The other issue is can we have quasi quotation of the type that Hadley >> > and >> > Lionel need in the language. This could be solved without allowing >> > user-defined unary specials, and we would probably want it to be, as I >> > doubt >> > ~ %!%x + %!%y + z is particularly aesthetically appealing to most (it >> > isn't >> > to me). I'd propose coopting unary @ for that myself. 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. >> > >> > Best, >> > ~G >> > >> > On Fri, Mar 17, 2017 at 5:10 AM, Jim Hester >> > wrote: >> >> >> >> I agree there is no reason they _need_ to be the same precedence, but >> >> I think SPECIALS are already have the
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 non-standard evaluation, unquoting (or perhaps interpolation) is essentially substituting part of an unevaluated expression with its evaluated value inlined. The unquote operator, then, is the way of marking which parts of the expression should be substituted in that way (i.e. interpolated). i.e. if uq() is the unquote "operator" and do_unquote interpolates, then if we have x = 5 exp = parse(text="f(uq(x)) + y +z") # expression: f(uq(x)) +y + z Then do_unquote would give you the *expression* f(5) + y + z In terms of what it does that the tilde does not, it would give you the ability to partially evaluate the captured formula/expression, without fully doing so. See the roxygen comments in Hadley and Lionel's rlang package here: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R The desired precedence of such a unary operator is not clear to me. The way rlang implements the !! now, it is quite low, so in the examples you see there the ~list(!! x + x) is transformed to ~list(10), not ~list(5+x) as I would have expected. I'm confused by this given what I understand the purpose to be, but that probably just means I'm not the right person to ask. Hope that helps. Best, ~G On Fri, Mar 17, 2017 at 8:55 AM, William Dunlapwrote: > >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 and show a few examples where is is useful, > intuitive, and fits in to R's functional design? In particular, > what does it give us that the current tilde function does not? > > > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > > On Fri, Mar 17, 2017 at 6:46 AM, Gabriel Becker > wrote: > > 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) that comes after it. Normal-style unary operators, on the other > > hand, explicitly don't want that. > > > > From what I can see, your patch provides support for the latter but not > the > > former. > > > > That said I think there are two issues here. One is can users define > unary > > operators. FWIW my opinion on that is roughly neutral to slightly > positive. > > The other issue is can we have quasi quotation of the type that Hadley > and > > Lionel need in the language. This could be solved without allowing > > user-defined unary specials, and we would probably want it to be, as I > doubt > > ~ %!%x + %!%y + z is particularly aesthetically appealing to most (it > isn't > > to me). I'd propose coopting unary @ for that myself. 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. > > > > Best, > > ~G > > > > On Fri, Mar 17, 2017 at 5:10 AM, Jim Hester > > wrote: > >> > >> 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 their own precedence I think it would end up in the > >> same place. > >> > >> `%l%` <- function(x) tail(x, n = 1) > >> %l% 1:5 > >> #> [1] 5 > >> %l% -5:-10 > >> #> [1] -10 > >> > >> On Thu, Mar 16, 2017 at 6:57 PM, William Dunlap > wrote: > >> > 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. > >> > Bill Dunlap > >> > TIBCO Software > >> > wdunlap tibco.com > >> > > >> > > >> > On Thu, Mar 16, 2017 at 3:18 PM, Michael Lawrence > >> > wrote: > >> >> 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). > >> >> > >> >>
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 and show a few examples where is is useful, intuitive, and fits in to R's functional design? In particular, what does it give us that the current tilde function does not? Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, Mar 17, 2017 at 6:46 AM, Gabriel Beckerwrote: > 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) that comes after it. Normal-style unary operators, on the other > hand, explicitly don't want that. > > From what I can see, your patch provides support for the latter but not the > former. > > That said I think there are two issues here. One is can users define unary > operators. FWIW my opinion on that is roughly neutral to slightly positive. > The other issue is can we have quasi quotation of the type that Hadley and > Lionel need in the language. This could be solved without allowing > user-defined unary specials, and we would probably want it to be, as I doubt > ~ %!%x + %!%y + z is particularly aesthetically appealing to most (it isn't > to me). I'd propose coopting unary @ for that myself. 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. > > Best, > ~G > > On Fri, Mar 17, 2017 at 5:10 AM, Jim Hester > wrote: >> >> 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 their own precedence I think it would end up in the >> same place. >> >> `%l%` <- function(x) tail(x, n = 1) >> %l% 1:5 >> #> [1] 5 >> %l% -5:-10 >> #> [1] -10 >> >> On Thu, Mar 16, 2017 at 6:57 PM, William Dunlap wrote: >> > 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. >> > Bill Dunlap >> > TIBCO Software >> > wdunlap tibco.com >> > >> > >> > On Thu, Mar 16, 2017 at 3:18 PM, Michael Lawrence >> > wrote: >> >> 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 addressed (eventually) in >> >> the >> >> core language, and it looks like people are already able to experiment, >> >> so >> >> I'm not sure there's a significant impetus for this change. >> >> >> >> Michael >> >> >> >> >> >> On Thu, Mar 16, 2017 at 10:51 AM, Jim Hester >> >> wrote: >> >> >> >>> 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 `f(1)` and infix >> >>> `1 + 1` operators, but we only provide a mechanism to create user >> >>> defined functional and infix operators. >> >>> >> >>> One could also argue that the user defined infix operators are also >> >>> ugly and could be replaced by `f(a, b)` calls as well; beauty is in >> >>> the eye of the beholder. >> >>> >> >>> The unquote example [1] shows one example where this gap in tooling >> >>> caused authors to co-opt existing unary exclamation operator, this >> >>> same gap is part of the reason the formula [2] and question mark [3] >> >>> operators have been used elsewhere in non standard contexts. >> >>> >> >>> If the language provided package authors with a native way to create >> >>> unary operators like it already does for the other operator types >> >>> these machinations would be unnecessary. >> >>> >> >>> [1]: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R#L17 >> >>> [2]: https://cran.r-project.org/package=ensurer >> >>> [3]: https://cran.r-project.org/package=types >> >>> >> >>> On Thu, Mar 16, 2017
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) that comes after it. Normal-style unary operators, on the other hand, explicitly don't want that. >From what I can see, your patch provides support for the latter but not the former. That said I think there are two issues here. One is can users define unary operators. FWIW my opinion on that is roughly neutral to slightly positive. The other issue is can we have quasi quotation of the type that Hadley and Lionel need in the language. This could be solved without allowing user-defined unary specials, and we would probably want it to be, as I doubt ~ %!%x + %!%y + z is particularly aesthetically appealing to most (it isn't to me). I'd propose coopting unary @ for that myself. 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. Best, ~G On Fri, Mar 17, 2017 at 5:10 AM, Jim Hesterwrote: > 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 their own precedence I think it would end up in the > same place. > > `%l%` <- function(x) tail(x, n = 1) > %l% 1:5 > #> [1] 5 > %l% -5:-10 > #> [1] -10 > > On Thu, Mar 16, 2017 at 6:57 PM, William Dunlap wrote: > > 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. > > Bill Dunlap > > TIBCO Software > > wdunlap tibco.com > > > > > > On Thu, Mar 16, 2017 at 3:18 PM, Michael Lawrence > > wrote: > >> 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 addressed (eventually) in > the > >> core language, and it looks like people are already able to experiment, > so > >> I'm not sure there's a significant impetus for this change. > >> > >> Michael > >> > >> > >> On Thu, Mar 16, 2017 at 10:51 AM, Jim Hester > >> wrote: > >> > >>> 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 `f(1)` and infix > >>> `1 + 1` operators, but we only provide a mechanism to create user > >>> defined functional and infix operators. > >>> > >>> One could also argue that the user defined infix operators are also > >>> ugly and could be replaced by `f(a, b)` calls as well; beauty is in > >>> the eye of the beholder. > >>> > >>> The unquote example [1] shows one example where this gap in tooling > >>> caused authors to co-opt existing unary exclamation operator, this > >>> same gap is part of the reason the formula [2] and question mark [3] > >>> operators have been used elsewhere in non standard contexts. > >>> > >>> If the language provided package authors with a native way to create > >>> unary operators like it already does for the other operator types > >>> these machinations would be unnecessary. > >>> > >>> [1]: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R#L17 > >>> [2]: https://cran.r-project.org/package=ensurer > >>> [3]: https://cran.r-project.org/package=types > >>> > >>> On Thu, Mar 16, 2017 at 1:04 PM, Gabriel Becker > >>> wrote: > >>> > Martin, > >>> > > >>> > Jim can speak directly to his motivations; I don't claim to be able > to do > >>> > so. That said, I suspect this is related to a conversation on twitter > >>> about > >>> > wanting an infix "unquote" operator in the context of the > non-standard > >>> > evaluation framework Hadley Wickham and Lionel Henry (and possibly > >>> others) > >>> > are working on. > >>> > > >>> > They're currently using !!! and !! for things related to this, but > this > >>> > effectively requires non-standard parsing, as ~!!x is interpreted as > >>> > ~(`!!`(x)) rather than ~(!(!(x)) as the R parser understands it. > Others > >>> and > >>> > I pointed
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 their own precedence I think it would end up in the same place. `%l%` <- function(x) tail(x, n = 1) %l% 1:5 #> [1] 5 %l% -5:-10 #> [1] -10 On Thu, Mar 16, 2017 at 6:57 PM, William Dunlapwrote: > 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. > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > > On Thu, Mar 16, 2017 at 3:18 PM, Michael Lawrence > wrote: >> 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 addressed (eventually) in the >> core language, and it looks like people are already able to experiment, so >> I'm not sure there's a significant impetus for this change. >> >> Michael >> >> >> On Thu, Mar 16, 2017 at 10:51 AM, Jim Hester >> wrote: >> >>> 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 `f(1)` and infix >>> `1 + 1` operators, but we only provide a mechanism to create user >>> defined functional and infix operators. >>> >>> One could also argue that the user defined infix operators are also >>> ugly and could be replaced by `f(a, b)` calls as well; beauty is in >>> the eye of the beholder. >>> >>> The unquote example [1] shows one example where this gap in tooling >>> caused authors to co-opt existing unary exclamation operator, this >>> same gap is part of the reason the formula [2] and question mark [3] >>> operators have been used elsewhere in non standard contexts. >>> >>> If the language provided package authors with a native way to create >>> unary operators like it already does for the other operator types >>> these machinations would be unnecessary. >>> >>> [1]: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R#L17 >>> [2]: https://cran.r-project.org/package=ensurer >>> [3]: https://cran.r-project.org/package=types >>> >>> On Thu, Mar 16, 2017 at 1:04 PM, Gabriel Becker >>> wrote: >>> > Martin, >>> > >>> > Jim can speak directly to his motivations; I don't claim to be able to do >>> > so. That said, I suspect this is related to a conversation on twitter >>> about >>> > wanting an infix "unquote" operator in the context of the non-standard >>> > evaluation framework Hadley Wickham and Lionel Henry (and possibly >>> others) >>> > are working on. >>> > >>> > They're currently using !!! and !! for things related to this, but this >>> > effectively requires non-standard parsing, as ~!!x is interpreted as >>> > ~(`!!`(x)) rather than ~(!(!(x)) as the R parser understands it. Others >>> and >>> > I pointed out this was less than desirable, but if something like it was >>> > going to happen it would hopefully happen in the language specification, >>> > rather than in a package (and also hopefully not using !! specifically). >>> > >>> > Like you, I actually tend to prefer the functional form myself in most >>> > cases. There are functional forms that would work for the above case >>> (e.g., >>> > something like the .() that DBI uses), but that's probably off topic >>> here, >>> > and not a decision I'm directly related to anyway. >>> > >>> > Best, >>> > ~G >>> > >>> > >>> > >>> > On Thu, Mar 16, 2017 at 9:51 AM, Martin Maechler >>> > wrote: >>> >> >>> >> > 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 unary + and -. Yes, both of your >>> >> > examples are valid with this patch, here are the results and >>> quoted >>> >> > forms to see the precedence. >>> >> >>> >> > `%chr%` <- function(x) as.character(x) >>> >> >>> >> [more efficient would be `%chr%` <- as.character] >>> >> >>> >> > `%identical%` <- function(x, y) identical(x, y) >>> >> > quote("100"
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 { force(a);force(b);cat("binary\n") } a <- 1 b <- 2 a %f% %f% b #> unary #> binary This also brings up the point about what happens to existing user defined functions such as `%in%` when they are used as unary functions (likely by mistake). Happily this provides a useful error when run assuming no default value of the second argument. %in% a #> Error in match(x, table, nomatch = 0L) : #> argument "table" is missing, with no default On Thu, Mar 16, 2017 at 7:13 PM, Duncan Murdochwrote: > 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 "a %chr% %chr% b" mean "%chr%(a, %chr% b)", or is it a syntax > error (like typing "a %chr%(%chr%(b))" would be)? > > Duncan Murdoch > > > > > > On 16/03/2017 10:24 AM, Jim Hester wrote: >> >> 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 >> #> [1] "100" >> >> %chr% 100 %identical% "100" >> #> [1] TRUE >> >> This seems a natural extension of the existing functionality and >> requires only a minor change to the grammar. If this change seems >> acceptable I am happy to provide a complete patch with suitable tests >> and documentation. >> >> [1]: >> Index: src/main/gram.y >> === >> --- src/main/gram.y (revision 72358) >> +++ src/main/gram.y (working copy) >> @@ -357,6 +357,7 @@ >> | '+' expr %prec UMINUS { $$ = xxunary($1,$2); >> setId( $$, @$); } >> | '!' expr %prec UNOT { $$ = xxunary($1,$2); >> setId( $$, @$); } >> | '~' expr %prec TILDE{ $$ = xxunary($1,$2); >> setId( $$, @$); } >> + | SPECIAL expr{ $$ = xxunary($1,$2); >> setId( $$, @$); } >> | '?' expr{ $$ = xxunary($1,$2); >> setId( $$, @$); } >> >> | expr ':' expr { $$ = >> xxbinary($2,$1,$3); setId( $$, @$); } >> >> __ >> 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
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 "a %chr% %chr% b" mean "%chr%(a, %chr% b)", or is it a syntax error (like typing "a %chr%(%chr%(b))" would be)? Duncan Murdoch On 16/03/2017 10:24 AM, Jim Hester wrote: 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 #> [1] "100" %chr% 100 %identical% "100" #> [1] TRUE This seems a natural extension of the existing functionality and requires only a minor change to the grammar. If this change seems acceptable I am happy to provide a complete patch with suitable tests and documentation. [1]: Index: src/main/gram.y === --- src/main/gram.y (revision 72358) +++ src/main/gram.y (working copy) @@ -357,6 +357,7 @@ | '+' expr %prec UMINUS { $$ = xxunary($1,$2); setId( $$, @$); } | '!' expr %prec UNOT { $$ = xxunary($1,$2); setId( $$, @$); } | '~' expr %prec TILDE{ $$ = xxunary($1,$2); setId( $$, @$); } + | SPECIAL expr{ $$ = xxunary($1,$2); setId( $$, @$); } | '?' expr{ $$ = xxunary($1,$2); setId( $$, @$); } | expr ':' expr { $$ = xxbinary($2,$1,$3); setId( $$, @$); } __ 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
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. Bill Dunlap TIBCO Software wdunlap tibco.com On Thu, Mar 16, 2017 at 3:18 PM, Michael Lawrencewrote: > 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 addressed (eventually) in the > core language, and it looks like people are already able to experiment, so > I'm not sure there's a significant impetus for this change. > > Michael > > > On Thu, Mar 16, 2017 at 10:51 AM, Jim Hester > wrote: > >> 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 `f(1)` and infix >> `1 + 1` operators, but we only provide a mechanism to create user >> defined functional and infix operators. >> >> One could also argue that the user defined infix operators are also >> ugly and could be replaced by `f(a, b)` calls as well; beauty is in >> the eye of the beholder. >> >> The unquote example [1] shows one example where this gap in tooling >> caused authors to co-opt existing unary exclamation operator, this >> same gap is part of the reason the formula [2] and question mark [3] >> operators have been used elsewhere in non standard contexts. >> >> If the language provided package authors with a native way to create >> unary operators like it already does for the other operator types >> these machinations would be unnecessary. >> >> [1]: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R#L17 >> [2]: https://cran.r-project.org/package=ensurer >> [3]: https://cran.r-project.org/package=types >> >> On Thu, Mar 16, 2017 at 1:04 PM, Gabriel Becker >> wrote: >> > Martin, >> > >> > Jim can speak directly to his motivations; I don't claim to be able to do >> > so. That said, I suspect this is related to a conversation on twitter >> about >> > wanting an infix "unquote" operator in the context of the non-standard >> > evaluation framework Hadley Wickham and Lionel Henry (and possibly >> others) >> > are working on. >> > >> > They're currently using !!! and !! for things related to this, but this >> > effectively requires non-standard parsing, as ~!!x is interpreted as >> > ~(`!!`(x)) rather than ~(!(!(x)) as the R parser understands it. Others >> and >> > I pointed out this was less than desirable, but if something like it was >> > going to happen it would hopefully happen in the language specification, >> > rather than in a package (and also hopefully not using !! specifically). >> > >> > Like you, I actually tend to prefer the functional form myself in most >> > cases. There are functional forms that would work for the above case >> (e.g., >> > something like the .() that DBI uses), but that's probably off topic >> here, >> > and not a decision I'm directly related to anyway. >> > >> > Best, >> > ~G >> > >> > >> > >> > On Thu, Mar 16, 2017 at 9:51 AM, Martin Maechler >> > wrote: >> >> >> >> > 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 unary + and -. Yes, both of your >> >> > examples are valid with this patch, here are the results and >> quoted >> >> > forms to see the precedence. >> >> >> >> > `%chr%` <- function(x) as.character(x) >> >> >> >> [more efficient would be `%chr%` <- as.character] >> >> >> >> > `%identical%` <- function(x, y) identical(x, y) >> >> > quote("100" %identical% %chr% 100) >> >> > #> "100" %identical% (`%chr%`(100)) >> >> >> >> > "100" %identical% %chr% 100 >> >> > #> [1] TRUE >> >> >> >> > `%num%` <- as.numeric >> >> > quote(1 + - %num% "5") >> >> > #> 1 + -(`%num%`("5")) >> >> >> >> > 1 + - %num% "5" >> >> > #> [1] -4 >> >> >> >> > Jim >> >> >> >> I'm sorry to be a bit of a spoiler to "coolness", but >> >> you may know that I like to applaud Norm Matloff for his book >> >> title "The Art of R Programming", >> >> because for me good code should also be beautiful to some extent. >> >> >> >> I really very much prefer >> >> >> >>f(x) >> >> to%f%
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 addressed (eventually) in the core language, and it looks like people are already able to experiment, so I'm not sure there's a significant impetus for this change. Michael On Thu, Mar 16, 2017 at 10:51 AM, Jim Hesterwrote: > 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 `f(1)` and infix > `1 + 1` operators, but we only provide a mechanism to create user > defined functional and infix operators. > > One could also argue that the user defined infix operators are also > ugly and could be replaced by `f(a, b)` calls as well; beauty is in > the eye of the beholder. > > The unquote example [1] shows one example where this gap in tooling > caused authors to co-opt existing unary exclamation operator, this > same gap is part of the reason the formula [2] and question mark [3] > operators have been used elsewhere in non standard contexts. > > If the language provided package authors with a native way to create > unary operators like it already does for the other operator types > these machinations would be unnecessary. > > [1]: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R#L17 > [2]: https://cran.r-project.org/package=ensurer > [3]: https://cran.r-project.org/package=types > > On Thu, Mar 16, 2017 at 1:04 PM, Gabriel Becker > wrote: > > Martin, > > > > Jim can speak directly to his motivations; I don't claim to be able to do > > so. That said, I suspect this is related to a conversation on twitter > about > > wanting an infix "unquote" operator in the context of the non-standard > > evaluation framework Hadley Wickham and Lionel Henry (and possibly > others) > > are working on. > > > > They're currently using !!! and !! for things related to this, but this > > effectively requires non-standard parsing, as ~!!x is interpreted as > > ~(`!!`(x)) rather than ~(!(!(x)) as the R parser understands it. Others > and > > I pointed out this was less than desirable, but if something like it was > > going to happen it would hopefully happen in the language specification, > > rather than in a package (and also hopefully not using !! specifically). > > > > Like you, I actually tend to prefer the functional form myself in most > > cases. There are functional forms that would work for the above case > (e.g., > > something like the .() that DBI uses), but that's probably off topic > here, > > and not a decision I'm directly related to anyway. > > > > Best, > > ~G > > > > > > > > On Thu, Mar 16, 2017 at 9:51 AM, Martin Maechler > > wrote: > >> > >> > 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 unary + and -. Yes, both of your > >> > examples are valid with this patch, here are the results and > quoted > >> > forms to see the precedence. > >> > >> > `%chr%` <- function(x) as.character(x) > >> > >> [more efficient would be `%chr%` <- as.character] > >> > >> > `%identical%` <- function(x, y) identical(x, y) > >> > quote("100" %identical% %chr% 100) > >> > #> "100" %identical% (`%chr%`(100)) > >> > >> > "100" %identical% %chr% 100 > >> > #> [1] TRUE > >> > >> > `%num%` <- as.numeric > >> > quote(1 + - %num% "5") > >> > #> 1 + -(`%num%`("5")) > >> > >> > 1 + - %num% "5" > >> > #> [1] -4 > >> > >> > Jim > >> > >> I'm sorry to be a bit of a spoiler to "coolness", but > >> you may know that I like to applaud Norm Matloff for his book > >> title "The Art of R Programming", > >> because for me good code should also be beautiful to some extent. > >> > >> I really very much prefer > >> > >>f(x) > >> to%f% x > >> > >> and hence I really really really cannot see why anybody would prefer > >> the ugliness of > >> > >>1 + - %num% "5" > >> to > >>1 + -num("5") > >> > >> (after setting num <- as.numeric ) > >> > >> Martin > >> > >> > >> > On Thu, Mar 16, 2017 at 12:01 PM, Gabriel Becker > >> wrote: > >> >> 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 > >>
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 `f(1)` and infix `1 + 1` operators, but we only provide a mechanism to create user defined functional and infix operators. One could also argue that the user defined infix operators are also ugly and could be replaced by `f(a, b)` calls as well; beauty is in the eye of the beholder. The unquote example [1] shows one example where this gap in tooling caused authors to co-opt existing unary exclamation operator, this same gap is part of the reason the formula [2] and question mark [3] operators have been used elsewhere in non standard contexts. If the language provided package authors with a native way to create unary operators like it already does for the other operator types these machinations would be unnecessary. [1]: https://github.com/hadley/rlang/blob/master/R/tidy-unquote.R#L17 [2]: https://cran.r-project.org/package=ensurer [3]: https://cran.r-project.org/package=types On Thu, Mar 16, 2017 at 1:04 PM, Gabriel Beckerwrote: > Martin, > > Jim can speak directly to his motivations; I don't claim to be able to do > so. That said, I suspect this is related to a conversation on twitter about > wanting an infix "unquote" operator in the context of the non-standard > evaluation framework Hadley Wickham and Lionel Henry (and possibly others) > are working on. > > They're currently using !!! and !! for things related to this, but this > effectively requires non-standard parsing, as ~!!x is interpreted as > ~(`!!`(x)) rather than ~(!(!(x)) as the R parser understands it. Others and > I pointed out this was less than desirable, but if something like it was > going to happen it would hopefully happen in the language specification, > rather than in a package (and also hopefully not using !! specifically). > > Like you, I actually tend to prefer the functional form myself in most > cases. There are functional forms that would work for the above case (e.g., > something like the .() that DBI uses), but that's probably off topic here, > and not a decision I'm directly related to anyway. > > Best, > ~G > > > > On Thu, Mar 16, 2017 at 9:51 AM, Martin Maechler > wrote: >> >> > 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 unary + and -. Yes, both of your >> > examples are valid with this patch, here are the results and quoted >> > forms to see the precedence. >> >> > `%chr%` <- function(x) as.character(x) >> >> [more efficient would be `%chr%` <- as.character] >> >> > `%identical%` <- function(x, y) identical(x, y) >> > quote("100" %identical% %chr% 100) >> > #> "100" %identical% (`%chr%`(100)) >> >> > "100" %identical% %chr% 100 >> > #> [1] TRUE >> >> > `%num%` <- as.numeric >> > quote(1 + - %num% "5") >> > #> 1 + -(`%num%`("5")) >> >> > 1 + - %num% "5" >> > #> [1] -4 >> >> > Jim >> >> I'm sorry to be a bit of a spoiler to "coolness", but >> you may know that I like to applaud Norm Matloff for his book >> title "The Art of R Programming", >> because for me good code should also be beautiful to some extent. >> >> I really very much prefer >> >>f(x) >> to%f% x >> >> and hence I really really really cannot see why anybody would prefer >> the ugliness of >> >>1 + - %num% "5" >> to >>1 + -num("5") >> >> (after setting num <- as.numeric ) >> >> Martin >> >> >> > On Thu, Mar 16, 2017 at 12:01 PM, Gabriel Becker >> wrote: >> >> 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 + - %num% "5" >> >> >> >> would also be legal (though quite ugly imo) and work? >> >> >> >> Best, >> >> ~G >> >> >> >> On Thu, Mar 16, 2017 at 7:24 AM, Jim Hester >> >> >> wrote: >> >>> >> >>> 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%` <-
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 unary + and -. Yes, both of your > examples are valid with this patch, here are the results and quoted > forms to see the precedence. > `%chr%` <- function(x) as.character(x) [more efficient would be `%chr%` <- as.character] > `%identical%` <- function(x, y) identical(x, y) > quote("100" %identical% %chr% 100) > #> "100" %identical% (`%chr%`(100)) > "100" %identical% %chr% 100 > #> [1] TRUE > `%num%` <- as.numeric > quote(1 + - %num% "5") > #> 1 + -(`%num%`("5")) > 1 + - %num% "5" > #> [1] -4 > Jim I'm sorry to be a bit of a spoiler to "coolness", but you may know that I like to applaud Norm Matloff for his book title "The Art of R Programming", because for me good code should also be beautiful to some extent. I really very much prefer f(x) to%f% x and hence I really really really cannot see why anybody would prefer the ugliness of 1 + - %num% "5" to 1 + -num("5") (after setting num <- as.numeric ) Martin > On Thu, Mar 16, 2017 at 12:01 PM, Gabriel Becker wrote: >> 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 + - %num% "5" >> >> would also be legal (though quite ugly imo) and work? >> >> Best, >> ~G >> >> On Thu, Mar 16, 2017 at 7:24 AM, Jim Hester >> wrote: >>> >>> 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 >>> #> [1] "100" >>> >>> %chr% 100 %identical% "100" >>> #> [1] TRUE >>> >>> This seems a natural extension of the existing functionality and >>> requires only a minor change to the grammar. If this change seems >>> acceptable I am happy to provide a complete patch with suitable tests >>> and documentation. >>> >>> [1]: >>> Index: src/main/gram.y >>> === >>> --- src/main/gram.y (revision 72358) >>> +++ src/main/gram.y (working copy) >>> @@ -357,6 +357,7 @@ >>> | '+' expr %prec UMINUS { $$ = xxunary($1,$2); >>> setId( $$, @$); } >>> | '!' expr %prec UNOT { $$ = xxunary($1,$2); >>> setId( $$, @$); } >>> | '~' expr %prec TILDE{ $$ = xxunary($1,$2); >>> setId( $$, @$); } >>> + | SPECIAL expr{ $$ = xxunary($1,$2); >>> setId( $$, @$); } >>> | '?' expr{ $$ = xxunary($1,$2); >>> setId( $$, @$); } >>> >>> | expr ':' expr { $$ = >>> xxbinary($2,$1,$3); setId( $$, @$); } >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> >> >> >> -- >> Gabriel Becker, PhD >> Associate Scientist (Bioinformatics) >> Genentech Research > __ > 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
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 precedence. `%chr%` <- function(x) as.character(x) `%identical%` <- function(x, y) identical(x, y) quote("100" %identical% %chr% 100) #> "100" %identical% (`%chr%`(100)) "100" %identical% %chr% 100 #> [1] TRUE `%num%` <- as.numeric quote(1 + - %num% "5") #> 1 + -(`%num%`("5")) 1 + - %num% "5" #> [1] -4 Jim On Thu, Mar 16, 2017 at 12:01 PM, Gabriel Beckerwrote: > 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 + - %num% "5" > > would also be legal (though quite ugly imo) and work? > > Best, > ~G > > On Thu, Mar 16, 2017 at 7:24 AM, Jim Hester > wrote: >> >> 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 >> #> [1] "100" >> >> %chr% 100 %identical% "100" >> #> [1] TRUE >> >> This seems a natural extension of the existing functionality and >> requires only a minor change to the grammar. If this change seems >> acceptable I am happy to provide a complete patch with suitable tests >> and documentation. >> >> [1]: >> Index: src/main/gram.y >> === >> --- src/main/gram.y (revision 72358) >> +++ src/main/gram.y (working copy) >> @@ -357,6 +357,7 @@ >> | '+' expr %prec UMINUS { $$ = xxunary($1,$2); >> setId( $$, @$); } >> | '!' expr %prec UNOT { $$ = xxunary($1,$2); >> setId( $$, @$); } >> | '~' expr %prec TILDE{ $$ = xxunary($1,$2); >> setId( $$, @$); } >> + | SPECIAL expr{ $$ = xxunary($1,$2); >> setId( $$, @$); } >> | '?' expr{ $$ = xxunary($1,$2); >> setId( $$, @$); } >> >> | expr ':' expr { $$ = >> xxbinary($2,$1,$3); setId( $$, @$); } >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > -- > Gabriel Becker, PhD > Associate Scientist (Bioinformatics) > Genentech Research __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 + - %num% "5" would also be legal (though quite ugly imo) and work? Best, ~G On Thu, Mar 16, 2017 at 7:24 AM, Jim Hesterwrote: > 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 > #> [1] "100" > > %chr% 100 %identical% "100" > #> [1] TRUE > > This seems a natural extension of the existing functionality and > requires only a minor change to the grammar. If this change seems > acceptable I am happy to provide a complete patch with suitable tests > and documentation. > > [1]: > Index: src/main/gram.y > === > --- src/main/gram.y (revision 72358) > +++ src/main/gram.y (working copy) > @@ -357,6 +357,7 @@ > | '+' expr %prec UMINUS { $$ = xxunary($1,$2); > setId( $$, @$); } > | '!' expr %prec UNOT { $$ = xxunary($1,$2); > setId( $$, @$); } > | '~' expr %prec TILDE{ $$ = xxunary($1,$2); > setId( $$, @$); } > + | SPECIAL expr{ $$ = xxunary($1,$2); > setId( $$, @$); } > | '?' expr{ $$ = xxunary($1,$2); > setId( $$, @$); } > > | expr ':' expr { $$ = > xxbinary($2,$1,$3); setId( $$, @$); } > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabriel Becker, PhD Associate Scientist (Bioinformatics) Genentech Research [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[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 #> [1] "100" %chr% 100 %identical% "100" #> [1] TRUE This seems a natural extension of the existing functionality and requires only a minor change to the grammar. If this change seems acceptable I am happy to provide a complete patch with suitable tests and documentation. [1]: Index: src/main/gram.y === --- src/main/gram.y (revision 72358) +++ src/main/gram.y (working copy) @@ -357,6 +357,7 @@ | '+' expr %prec UMINUS { $$ = xxunary($1,$2); setId( $$, @$); } | '!' expr %prec UNOT { $$ = xxunary($1,$2); setId( $$, @$); } | '~' expr %prec TILDE{ $$ = xxunary($1,$2); setId( $$, @$); } + | SPECIAL expr{ $$ = xxunary($1,$2); setId( $$, @$); } | '?' expr{ $$ = xxunary($1,$2); setId( $$, @$); } | expr ':' expr { $$ = xxbinary($2,$1,$3); setId( $$, @$); } __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel