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 packag
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 get
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
communit
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 lar
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 schedul
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 !!!
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 t
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(langu
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-standar
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 Tiern
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)3815350
>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 a
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
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:1
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) tha
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
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
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 {
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
19 matches
Mail list logo
