From luke at stat.uiowa.edu  Wed Jul  2 16:57:18 2008
From: luke at stat.uiowa.edu (Luke Tierney)
Date: Wed, 2 Jul 2008 09:57:18 -0500 (CDT)
Subject: [Rd] get ...
In-Reply-To: <486ACBD2.60409@stats.uwo.ca>
References: <971536df0806281246o75249479gaab3a059952e0f85@mail.gmail.com>
	<4866A174.4050706@biostat.ku.dk>
	<alpine.LFD.1.10.0806300950510.2815@nokomis.stat.uiowa.edu>
	<486ACBD2.60409@stats.uwo.ca>
Message-ID: <Pine.LNX.4.64.0807020952220.18218@itasca2.wildberry.org>

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:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu



[Rd] get ...
Luke Tierney