[Rd] get ...

[Luke Tierney]

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