Re: [Rd] Support for user defined unary functions

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

Re: [Rd] Support for user defined unary functions

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

Re: [Rd] Support for user defined unary functions

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

[Rd] Hyperbolic tangent different results on Windows and Mac

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

Re: [Rd] R 3.4.0

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

Re: [Rd] Support for user defined unary functions

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

Re: [Rd] Support for user defined unary functions

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

Re: [Rd] Support for user defined unary functions

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

Re: [Rd] Support for user defined unary functions

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

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

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

[Bioc-devel] Update on package evaluation

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

[Bioc-devel] Perl version issue with building Rhtslib

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:

Re: [Rd] R 3.4.0

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

[Rd] R 3.4.0

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:

Re: [Rd] Support for user defined unary functions

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

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

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

Re: [Bioc-devel] Update devel branch

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

[Bioc-devel] Update devel branch

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

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

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

Re: [Rd] Support for user defined unary functions

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

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

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

Re: [Rd] Support for user defined unary functions

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

Re: [Rd] Support for user defined unary functions

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

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

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