ML> For the uqs() thing, expanding calls like that is somewhat orthogonal
ML> to NSE. It would be nice in general to be able to write something like
ML> mean(x, extra_args...) without resorting to do.call(mean, c(list(x),
ML> extra_args)).
This is not completely true because splicing is necessari
RN> There is an opportunity cost to grabbing the presently-unused unary @
RN> operator for this
I don't think this is the case because the parser has to interpret `@`
in formal argument lists in a different way than in function calls.
Besides, it'd make sense to set up these annotations with a b
On Mon, Mar 20, 2017 at 8:00 AM, Hadley Wickham wrote:
> On Mon, Mar 20, 2017 at 7:36 AM, Radford Neal wrote:
>> Michael Lawrence (as last in long series of posters)...
>>
>>> Yes, it would bind the language object to the environment, like an
>>> R-level promise (but "promise" of course refers sp
On Mon, Mar 20, 2017 at 7:36 AM, Radford Neal wrote:
> Michael Lawrence (as last in long series of posters)...
>
>> Yes, it would bind the language object to the environment, like an
>> R-level promise (but "promise" of course refers specifically to just
>> _lazy_ evaluation).
>>
>> For the uqs()
Michael Lawrence (as last in long series of posters)...
> Yes, it would bind the language object to the environment, like an
> R-level promise (but "promise" of course refers specifically to just
> _lazy_ evaluation).
>
> For the uqs() thing, expanding calls like that is somewhat orthogonal
> to
Yes, it would bind the language object to the environment, like an
R-level promise (but "promise" of course refers specifically to just
_lazy_ evaluation).
For the uqs() thing, expanding calls like that is somewhat orthogonal
to NSE. It would be nice in general to be able to write something like
m
Firstly, credit where due: the lazyeval NSE vignette [1] covers so many of
the angles that this proposal needs to address and is extremely well
written (even if it has been superseded). The @ prefix I'm proposing is a
drop-in replacement for `uq()` (as used in that vignette) but for which the
`f_ev
Would this return a quosure? (i.e. a single sided formula that captures
both expression and environment). That's the data structure we've adopted
in tidyeval as it already has some built in support.
Hadley
On Friday, March 17, 2017, Michael Lawrence
wrote:
> Interesting idea. Lazy and non-stand
What would you propose for the unquote-splice operator?
Hadley
On Friday, March 17, 2017, 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 s
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
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
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
(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 Twitt
14 matches
Mail list logo