get ...

[Gabor Grothendieck]

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?

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Peter Dalgaard]

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

--
   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark      Ph:  ([phone]
~~~~~~~~~~ - (p.dalgaard@...)              FAX: [phone]

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Luke Tierney]

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.

luke

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

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Duncan Murdoch-2]

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.

Duncan Murdoch

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Luke Tierney]

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

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Gabor Grothendieck]

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

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Duncan Murdoch-2]

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@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel