Thanks, this was what I expected. There is a desire to eliminate the
usage of pairlist from user code, which suggests the alternative of
allowing for function arguments to be stored in lists. That's a much
deeper change though.
On Wed, Oct 12, 2016 at 12:31 PM, Henrik Bengtsson
wrote:
> Michael,
Michael, thanks for this info.
I've stumbled upon this in a case where I walk an R expression (the
AST) and (optionally) modifies it (part of the globals package). In R
expressions, a function definition uses a pairlist to represent the
arguments. For example,
> expr <- quote(function(x = 1) x)
Hi Henrik,
It would help to understand your use case for pairlists.
Thanks,
Michael
On Wed, Oct 12, 2016 at 9:40 AM, Michael Lawrence wrote:
> The coercion is probably the most viable workaround for now, as it's
> consistent with what happens internally for calls. All pairlists/calls
> are conv
The coercion is probably the most viable workaround for now, as it's
consistent with what happens internally for calls. All pairlists/calls
are converted to list for subassignment, but only calls are converted
back. My guess is that the intent was for users to move from using a
pairlist to the "new
Hi, I seem to not be able to assign NULL to an element of a pairlist
without causing it to be coerced to a plain list. For example:
> x <- pairlist(1, 2)
> class(x)
[1] "pairlist"
> x[1] <- list(NULL)
> class(x)
[1] "list"
This actually true for all [()<- assignments regardless of list value, e
Hi!
We noticed that these error messages were changed to include the name of the
function that causes them:
> { x<-c(1,2); x[[c("a", "b")]] }
old: “Error in x[[c("a", "b")]] : attempt to select more than one element”
new: “Error in x[[c("a", "b")]] : attempt to select more than one element in
ve
