Re: [Rd] Support for user defined unary functions

[Dirk Eddelbuettel]

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

[William Dunlap via R-devel]

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 Hester  wrote:
> 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

[Jim Hester]

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, 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]: 

[Rd] Hyperbolic tangent different results on Windows and Mac

[Rodrigo Zepeda]

Dear all,

We seem to have found a "strange" behaviour in the hyperbolic tangent
function tanh on Windows.
When running tanh(356 + 0i) the Windows result is NaN + 0.i while on Mac
the result is 1 + 0i. It doesn't seem to be a floating point error because
on Mac it is possible to run arbitrarily large numbers (say tanh(
99677873648767519238192348124812341234182374817239847812738481234871823+0i)
) and still get 1 + 0i as result. This seems to be related to the imaginary
part as tanh(356) returns 1 in both Windows and Mac.

We have obtained those results in:
1) Mac with El Capitan v 10.11.6 *processor: 2.7 GHz Intel Core i5*
- 2) Mac with Sierra v 10.12.3 *processor: 3.2 GHz Intel Core i5*
- 3) Windows 10 Home v 1607 *processor: Intel Core m3-SY30 CPU@ 0.90 GHz
1.51 GHz*
- 4) Windows 7 Home Premium Service Pack 1 *processor: Intel Core i5-2410M
CPU @2.30 GHz 2.30GHz.*

​In all cases we are using R version 3.3.3 (64 bits)​

- *Does anybody have a clue on why is this happening?*
-
​PS: We have previously posted this issue in Stack Overflow (
http://stackoverflow.com/questions/42847414/hyperbolic-tangent-in-r-throws-nan-in-windows-but-not-in-mac).
A comment suggests it is related to a glibc bug.

​
​Thanks,​
Rod

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R 3.4.0

[Avraham Adler]

Perhaps the darkness is so stupid it forgot to update the year?

Avi
On Fri, Mar 17, 2017 at 12:24 PM  wrote:

> Your dates are for 2016 :-) in your email and developer.r-project.com
>
> Best,
>
> luke
>
> On Fri, 17 Mar 2017, Peter Dalgaard wrote:
>
> > R 3.4.0 "You Stupid Darkness" is now scheduled for April 21
> >
> > The detailed schedule can be found on developer.r-project.org
> >
> > For the Core Team
> >
> > Peter D.
> >
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa  Phone: 319-335-3386
> Department of Statistics andFax:   319-335-3017
> Actuarial Science
> 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Support for user defined unary functions

[William Dunlap via R-devel]

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 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

[Gabriel Becker]

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 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

[William Dunlap via R-devel]

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.
>> >
>> > 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

[Gabriel Becker]

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 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).
> >> >>
> >> >> 

[Bioc-devel] new package submission deadline for Bioconductor 3.5

[Shepherd, Lori]

Hello,

The new package submission deadline is March 31. This deadline will serve as 
the potential to be included in release 3.5 pending review; packages after this 
deadline will remain in Bioconductor devel pending proper review.

Thank you.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Update on package evaluation

[Sadiq Saleh]

My package STROMA4 has had a successful build for over a month, but there
has been no update on the evaluation. I have posted a question on my
package page for the assigned evaluator but have not received a response.
Would it be possible to provide a status update?

Sadiq Saleh

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Perl version issue with building Rhtslib

[Dinakar Kulkarni]

Hello,

The following error was generated while attempting to install the "Rhtslib"
package in R v3.3.2:

/usr/bin/perl: symbol lookup error: /perl-modules/5.18.2/1.142660/x86_64-
linux-2.6-rhel6/lib/perl5/x86_64-linux-thread-multi/auto/List/Util/Util.so:
undefined symbol: Perl_xs_apiversion_bootcheck

WARNING: 'autoconf' is missing on your system.

 You should only need it if you modified 'configure.ac',

 or m4 files included by it.

 The 'autoconf' program is part of the GNU Autoconf package:

 

 It also requires GNU m4 and Perl in order to run:

 

 

make[1]: *** [configure] Error 127

make[1]: Leaving directory `/tmp/Rtmpn6FFZH/R.INSTALL671e
4ed4c86d/Rhtslib/src/htslib'

make: *** [htslib/libhts.la] Error 2

ERROR: compilation failed for package ‘Rhtslib’

On further investigation, I was able to determine that the default Perl
version on the OS (RHEL 6.6) was v5.10.1, so it turned out to be an
incompatibility issue.

I looked into the source for Rhtslib and see that it use these 3 Perl
scripts:

Rhtslib/src/htslib/test/compare_sam.pl
Rhtslib/src/htslib/test/test.pl
Rhtslib/src/htslib/test/test_view.pl

and they use the default env Perl. I believe that it would be better to
specify the Perl version within these scripts(i.e. use v5.18.2) for
compiling/building the package. I've attached suggested patch files here
for the same.

Thanks,
Dinakar.

-- 
Dinakar Kulkarni
Genentech, Inc.
kulkarni.dina...@gene.com
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] R 3.4.0

[luke-tierney]

Your dates are for 2016 :-) in your email and developer.r-project.com

Best,

luke

On Fri, 17 Mar 2017, Peter Dalgaard wrote:


R 3.4.0 "You Stupid Darkness" is now scheduled for April 21

The detailed schedule can be found on developer.r-project.org

For the Core Team

Peter D.




--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] R 3.4.0

[Peter Dalgaard]

R 3.4.0 "You Stupid Darkness" is now scheduled for April 21

The detailed schedule can be found on developer.r-project.org

For the Core Team

Peter D.

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Support for user defined unary functions

[William Dunlap via R-devel]

>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).
>> >>
>> >> 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] RFC: (in-principle) native unquoting for standard evaluation

[Gabriel Becker]

Jonathan,

Nice proposal.

I think these two uses for unary @ ( your initial @ unary operator and
Michael's extension for use inside function declaration) synergize really
well. It could easily be that function owners can declare an parameter to
always quote, and function callers can their specific arguments to behave
in the way you describe. It would make @ mean two pretty different things
in these two contexts, but they aren't^ mixable, so I think that would be
ok. This also has a strong precedence with the * operator in C, where int
*a creates a pointer, and then *a +1 uses the dereferenced value.

^ I think they're only not mixable provided that the function function
itself does not support your (Jonathan's) version of the operator, i.e.,
the ability to use variables' values to declare parameter names  or default
values within the function declaration. (Actually I think it could be
supported for default values, just not parameter names, if we wanted to) I
think that's reasonable though. I don't think we would need to support that.

One big question is whether you can do function(x, y, @...). The definition
of mutate() using Michaels extension of your proposal would require this.
This would be in keeping with the principle of the proposal, I think,
though it might (or might not) make the implementation more complicated.

I wonder if it makes sense to have a formal ability to declare where the
NSE will take place in the function definition, perhaps, (completely
spitballing) a unary ^ operator, so a simplified subset could literally be
defined as

subset2 = function(^x,  @cond) x[cond,]

Perhaps that's getting too clever, but it could be cool. Note it would be
optional. And we might even want a different different operators for that,
since it changes what the @ modifier of the parameter does. (your code gets
the result of the expression being evaluated in the ^ context, rather than
the language object). This would be, I imagine, immensely useful when
attempting to compile code that is NSE, even beyond labeling it as such via
the @ in function declarations

Best,
~G


On Fri, Mar 17, 2017 at 6:16 AM, Jonathan Carroll 
wrote:

> I love the pointer analogy. Presumably the additional complication of scope
> breaks this however. * itself would have been a nice operator for this were
> it not prone to ambiguity (`a * *b` vs `a**b`, from which @ does not
> suffer).
>
> Would this extension require that function authors explicitly enable
> auto-quoting support? I somewhat envisioned functions seeing the resolved
> unquoted object (within their calling scope) so that they could retain
> their standard defintions when not using @. In my mutate example, mutate
> itself could simply be the NSE version, so
>
> mutate(mtcars, z = mpg)
>
> would work as normal, but
>
> x = "mpg"
> mutate(mtcars, z = @x)
>
> would produce the same result (x may be changing within a loop or be
> defined through a formal argument). Here, @x would resolve to `mpg` and
> mutate would retain the duty of resolving that to mtcars$mpg as per normal.
>
> A seperate SE version would not be required (as arguments could be set
> programatically), but an additional flexibility could be @ acting on a
> string rather than an object for direct unquoting
>
> mutate(mtcars, z = @"mpg")
>
> for when the name is known but NSE isn't desired (which would also assist
> with the whole utils::globalVariables() vs CRAN checks concern).
>
> Having a formal argument forcefully auto-unquote would prevent standard
> usage unless there was a way to also disable it. Unless I'm missing an
> angle (which I very likely am) wouldn't it be better to have the user
> supply an @-prefixed argument and retain the connection to the calling
> scope?
>
> Apologies if I have any of that confused or there are better approaches. I
> merely have a desire for this to work and am learning as much as possible
> about "how" as I go.
>
> Your comments are greatly appreciated.
>
> - Jonathan.
>
> On Fri, 17 Mar 2017 at 21:00, Michael Lawrence 
> wrote:
>
> Interesting idea. Lazy and non-standard evaluation is going to happen; the
> language needs a way to contain it.
>
> I'll extend the proposal so that prefixing a formal argument with @ in
> function() marks the argument as auto-quoting, so it arrives as a language
> object without use of substitute(). Kind of like how '*' in C declares a
> pointer and dereferences one.
>
> subset <- function(x, @subset, ...) { }
>
> This should make it easier to implement such functions, simplify
> compilation, and allow detection of potential quoting errors through static
> analysis.
>
> Michael
>
> On Thu, Mar 16, 2017 at 5:03 PM, Jonathan Carroll 
> wrote:
>
> (please be gentle, it's my first time)
>
> I am interested in discussions (possibly reiterating past threads --
> searching didn't turn up much) on the possibility of supporting standard
> evaluation unquoting 

Re: [Bioc-devel] Update devel branch

[Vincent Carey]

see http://bioconductor.org/developers/how-to/source-control/

from which I infer

svn co https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/BaalChIP

will give you a clean checkout of current devel source

you make changes in there

then in the BaalChIP folder, do svn commit

 you should do CMD build and check before committing

On Fri, Mar 17, 2017 at 10:39 AM, Ines de Santiago <
ines.desanti...@cruk.cam.ac.uk> wrote:

> May seem like a simple question,
> But I don’t know how to commit changes to the level branch of my Package
> (BaalChIP) - I want to update my email and citation for the new release 3.5,
> Thank you.
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Update devel branch

[Ines de Santiago]

May seem like a simple question,
But I don’t know how to commit changes to the level branch of my Package 
(BaalChIP) - I want to update my email and citation for the new release 3.5,
Thank you.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] RFC: (in-principle) native unquoting for standard evaluation

[Michael Lawrence]

Not sure I totally understand what you wrote, but my proposal is somewhat
independent of the unquoting during the call (your proposal). Authors would
be free to either use auto-quoting or continue to rely on the substitute()
mechanism. Lazy evaluation wouldn't go away.


On Fri, Mar 17, 2017 at 6:16 AM, Jonathan Carroll 
wrote:

> I love the pointer analogy. Presumably the additional complication of scope
> breaks this however. * itself would have been a nice operator for this were
> it not prone to ambiguity (`a * *b` vs `a**b`, from which @ does not
> suffer).
>
> Would this extension require that function authors explicitly enable
> auto-quoting support? I somewhat envisioned functions seeing the resolved
> unquoted object (within their calling scope) so that they could retain
> their standard defintions when not using @. In my mutate example, mutate
> itself could simply be the NSE version, so
>
> mutate(mtcars, z = mpg)
>
> would work as normal, but
>
> x = "mpg"
> mutate(mtcars, z = @x)
>
> would produce the same result (x may be changing within a loop or be
> defined through a formal argument). Here, @x would resolve to `mpg` and
> mutate would retain the duty of resolving that to mtcars$mpg as per normal.
>
> A seperate SE version would not be required (as arguments could be set
> programatically), but an additional flexibility could be @ acting on a
> string rather than an object for direct unquoting
>
> mutate(mtcars, z = @"mpg")
>
> for when the name is known but NSE isn't desired (which would also assist
> with the whole utils::globalVariables() vs CRAN checks concern).
>
> Having a formal argument forcefully auto-unquote would prevent standard
> usage unless there was a way to also disable it. Unless I'm missing an
> angle (which I very likely am) wouldn't it be better to have the user
> supply an @-prefixed argument and retain the connection to the calling
> scope?
>
> Apologies if I have any of that confused or there are better approaches. I
> merely have a desire for this to work and am learning as much as possible
> about "how" as I go.
>
> Your comments are greatly appreciated.
>
> - Jonathan.
>
> On Fri, 17 Mar 2017 at 21:00, Michael Lawrence 
> wrote:
>
> Interesting idea. Lazy and non-standard evaluation is going to happen; the
> language needs a way to contain it.
>
> I'll extend the proposal so that prefixing a formal argument with @ in
> function() marks the argument as auto-quoting, so it arrives as a language
> object without use of substitute(). Kind of like how '*' in C declares a
> pointer and dereferences one.
>
> subset <- function(x, @subset, ...) { }
>
> This should make it easier to implement such functions, simplify
> compilation, and allow detection of potential quoting errors through static
> analysis.
>
> Michael
>
> On Thu, Mar 16, 2017 at 5:03 PM, Jonathan Carroll 
> wrote:
>
> (please be gentle, it's my first time)
>
> I am interested in discussions (possibly reiterating past threads --
> searching didn't turn up much) on the possibility of supporting standard
> evaluation unquoting at the language level. This has been brought up in a
> recent similar thread here [1] and on Twitter [2] where I proposed the
> following desired (in-principle) syntax
>
> f <- function(col1, col2, new_col_name) {
> mtcars %>% mutate(@new_col_name = @col1 + @col2)
> }
>
> or closer to home
>
> x <- 1:10; y <- "x"
> data.frame(z = @y)
>
> where @ would be defined as a unary prefix operator which substitutes the
> quoted variable name in-place, to allow more flexibility of NSE functions
> within a programming context. This mechanism exists within MySQL [3] (and
> likely other languages) and could potentially be extremely useful. Several
> alternatives have been incorporated into packages (most recently work
> on tidyeval) none of which appear to fully match the simplicity of the
> above, and some of which cut a forceful path through the syntax tree.
>
> The exact syntax isn't my concern at the moment (@ vs unquote() or other,
> though the first requires user-supplied native prefix support within the
> language, as per [1]) and neither is the exact way in which this would be
> achieved (well above my pay grade). The practicality of @ being on the LHS
> of `=` is also of a lesser concern (likely greater complexity) than the
> RHS.
>
> I hear there exists (justified) reluctance to add new syntax to the
> language, but I think this has sufficient merit (and a growing number of
> workarounds) to warrant continued discussion.
>
> With kindest regards,
>
> - Jonathan.
>
> [1] https://stat.ethz.ch/pipermail/r-devel/2017-March/073894.html
> [2] https://twitter.com/carroll_jono/status/842142292253196290
> [3] https://dev.mysql.com/doc/refman/5.7/en/user-variables.html
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org 

Re: [Rd] Support for user defined unary functions

[Gabriel Becker]

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 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] RFC: (in-principle) native unquoting for standard evaluation

[Jonathan Carroll]

I love the pointer analogy. Presumably the additional complication of scope
breaks this however. * itself would have been a nice operator for this were
it not prone to ambiguity (`a * *b` vs `a**b`, from which @ does not
suffer).

Would this extension require that function authors explicitly enable
auto-quoting support? I somewhat envisioned functions seeing the resolved
unquoted object (within their calling scope) so that they could retain
their standard defintions when not using @. In my mutate example, mutate
itself could simply be the NSE version, so

mutate(mtcars, z = mpg)

would work as normal, but

x = "mpg"
mutate(mtcars, z = @x)

would produce the same result (x may be changing within a loop or be
defined through a formal argument). Here, @x would resolve to `mpg` and
mutate would retain the duty of resolving that to mtcars$mpg as per normal.

A seperate SE version would not be required (as arguments could be set
programatically), but an additional flexibility could be @ acting on a
string rather than an object for direct unquoting

mutate(mtcars, z = @"mpg")

for when the name is known but NSE isn't desired (which would also assist
with the whole utils::globalVariables() vs CRAN checks concern).

Having a formal argument forcefully auto-unquote would prevent standard
usage unless there was a way to also disable it. Unless I'm missing an
angle (which I very likely am) wouldn't it be better to have the user
supply an @-prefixed argument and retain the connection to the calling
scope?

Apologies if I have any of that confused or there are better approaches. I
merely have a desire for this to work and am learning as much as possible
about "how" as I go.

Your comments are greatly appreciated.

- Jonathan.

On Fri, 17 Mar 2017 at 21:00, Michael Lawrence 
wrote:

Interesting idea. Lazy and non-standard evaluation is going to happen; the
language needs a way to contain it.

I'll extend the proposal so that prefixing a formal argument with @ in
function() marks the argument as auto-quoting, so it arrives as a language
object without use of substitute(). Kind of like how '*' in C declares a
pointer and dereferences one.

subset <- function(x, @subset, ...) { }

This should make it easier to implement such functions, simplify
compilation, and allow detection of potential quoting errors through static
analysis.

Michael

On Thu, Mar 16, 2017 at 5:03 PM, Jonathan Carroll 
wrote:

(please be gentle, it's my first time)

I am interested in discussions (possibly reiterating past threads --
searching didn't turn up much) on the possibility of supporting standard
evaluation unquoting at the language level. This has been brought up in a
recent similar thread here [1] and on Twitter [2] where I proposed the
following desired (in-principle) syntax

f <- function(col1, col2, new_col_name) {
mtcars %>% mutate(@new_col_name = @col1 + @col2)
}

or closer to home

x <- 1:10; y <- "x"
data.frame(z = @y)

where @ would be defined as a unary prefix operator which substitutes the
quoted variable name in-place, to allow more flexibility of NSE functions
within a programming context. This mechanism exists within MySQL [3] (and
likely other languages) and could potentially be extremely useful. Several
alternatives have been incorporated into packages (most recently work
on tidyeval) none of which appear to fully match the simplicity of the
above, and some of which cut a forceful path through the syntax tree.

The exact syntax isn't my concern at the moment (@ vs unquote() or other,
though the first requires user-supplied native prefix support within the
language, as per [1]) and neither is the exact way in which this would be
achieved (well above my pay grade). The practicality of @ being on the LHS
of `=` is also of a lesser concern (likely greater complexity) than the RHS.

I hear there exists (justified) reluctance to add new syntax to the
language, but I think this has sufficient merit (and a growing number of
workarounds) to warrant continued discussion.

With kindest regards,

- Jonathan.

[1] https://stat.ethz.ch/pipermail/r-devel/2017-March/073894.html
[2] https://twitter.com/carroll_jono/status/842142292253196290
[3] https://dev.mysql.com/doc/refman/5.7/en/user-variables.html

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Support for user defined unary functions

[Jim Hester]

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 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

[Jim Hester]

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 Murdoch
 wrote:
> 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] RFC: (in-principle) native unquoting for standard evaluation

[Michael Lawrence]

Interesting idea. Lazy and non-standard evaluation is going to happen; the
language needs a way to contain it.

I'll extend the proposal so that prefixing a formal argument with @ in
function() marks the argument as auto-quoting, so it arrives as a language
object without use of substitute(). Kind of like how '*' in C declares a
pointer and dereferences one.

subset <- function(x, @subset, ...) { }

This should make it easier to implement such functions, simplify
compilation, and allow detection of potential quoting errors through static
analysis.

Michael

On Thu, Mar 16, 2017 at 5:03 PM, Jonathan Carroll 
wrote:

> (please be gentle, it's my first time)
>
> I am interested in discussions (possibly reiterating past threads --
> searching didn't turn up much) on the possibility of supporting standard
> evaluation unquoting at the language level. This has been brought up in a
> recent similar thread here [1] and on Twitter [2] where I proposed the
> following desired (in-principle) syntax
>
> f <- function(col1, col2, new_col_name) {
> mtcars %>% mutate(@new_col_name = @col1 + @col2)
> }
>
> or closer to home
>
> x <- 1:10; y <- "x"
> data.frame(z = @y)
>
> where @ would be defined as a unary prefix operator which substitutes the
> quoted variable name in-place, to allow more flexibility of NSE functions
> within a programming context. This mechanism exists within MySQL [3] (and
> likely other languages) and could potentially be extremely useful. Several
> alternatives have been incorporated into packages (most recently work
> on tidyeval) none of which appear to fully match the simplicity of the
> above, and some of which cut a forceful path through the syntax tree.
>
> The exact syntax isn't my concern at the moment (@ vs unquote() or other,
> though the first requires user-supplied native prefix support within the
> language, as per [1]) and neither is the exact way in which this would be
> achieved (well above my pay grade). The practicality of @ being on the LHS
> of `=` is also of a lesser concern (likely greater complexity) than the
> RHS.
>
> I hear there exists (justified) reluctance to add new syntax to the
> language, but I think this has sufficient merit (and a growing number of
> workarounds) to warrant continued discussion.
>
> With kindest regards,
>
> - Jonathan.
>
> [1] https://stat.ethz.ch/pipermail/r-devel/2017-March/073894.html
> [2] https://twitter.com/carroll_jono/status/842142292253196290
> [3] https://dev.mysql.com/doc/refman/5.7/en/user-variables.html
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel