[Rd] get ...

[Duncan Murdoch]

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