ACCESS TO WHAT FOR CRYING OUT LOUD!!!!!! What we have now is a way for
a useless internal object that is in any case subject to change to
leak out. How is that useful, never mind essential? Exists works, as
it should, ls works, as it should. In the language, ... arguments in
functions are special, so it is appropriate for variables named
... that are being used in the special context (i.e. have values that
are R_DOTSXP) to behave in a special way, as do variables in
environments that correspond to missing arguments in functions. The
behavior of assign("...", x, env = e) will not be unaffected for any
valye of x accessible at the R level.
luke
On Wed, 2 Jul 2008, Gabor Grothendieck wrote:
If access is removed it would be important to provide
an alternative first -- removing access and only providing
an alternative some time later does not seem prudent.
On Wed, Jul 2, 2008 at 10:57 AM, Luke Tierney <[EMAIL PROTECTED]> 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.
luke
Duncan Murdoch
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
