On 7/2/2008 10:57 AM, Luke Tierney wrote:
On Tue, 1 Jul 2008, Duncan Murdoch wrote:
On 30/06/2008 10:56 AM, Luke Tierney wrote:
On Sat, 28 Jun 2008, Peter Dalgaard wrote:
Gabor Grothendieck wrote:
Suppose we do this:
f <- function(...) environment()
e <- f(a = 1, b = 2)
ls(e, all = TRUE)
[1] "..."
e$...
<...>
class(e$...)
[1] "..."
Is there any way of getting a and b given e without
modifying f?
evalq(list(...),e)
$a
[1] 1
$b
[1] 2
I'm wondering though whether we should allow the internal DOTSXP value
of "..." to escape to the user level. Might be more appropriate for
get(e,"..."), e$... (and as.list.environment and maybe a few other
things) to give the "Error: '...' used in an incorrect context" error
if the value is a DOTSXP.
On the other hand, what Gabor sees in e is what he would see inside f:
f <- function(...) { ls(all=T) }
f(a=1, b=2)
[1] "..."
I don't think we should distinguish between user level in .GlobalEnv and what
a user sees inside a function he writes. Stopping a user from seeing ...
inside a function would break all sorts of things.
Huh??
Noone is proposing that ls or exist, for example change. ... is a
special variable that can only be used in special contexts. Just
evaluating ... gives an error; get("...") used in the same context
probably ought to as well. What we do now is clearly wrong: return an
undocumented object that can't be used for anyting useful (and
reflects an internal implementation we might want to change). We need
to either prevent the R_DOTSXP values from leaking out or document
them , define [ methods and figure out what they should do, etc.
Preventing them from leaking out is the sensible thing to do.
Sorry, I misunderstood what you were suggesting. So you wouldn't
propose to change the behaviour of Peter's evalq(list(...),e)?
Duncan Murdoch
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
