get ... - R-devel | R Mailing Lists

Tue, Jul 1, 2008 5:29 PM #

On 30/06/2008 10:56 AM, Luke Tierney wrote:

On the other hand, what Gabor sees in e is what he would see inside f:

[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

Luke Tierney

Wed, Jul 2, 2008 7:57 AM #

On Tue, 1 Jul 2008, Duncan Murdoch wrote:

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

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

Gabor Grothendieck

Wed, Jul 2, 2008 8:03 AM #

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

Wed, Jul 2, 2008 8:24 AM #

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

Duncan Murdoch

Wed, Jul 2, 2008 8:27 AM #

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