Re: [R] scoping rules
Whit Armstrong tudor.com> writes:
:
: Can someone help me with this simple example?
:
: sq <- function() {
: y <- x^2
: y
: }
:
: myfunc <- function() {
: x <- 10
: sq()
: }
:
: myfunc()
:
: executing the above in R yields:
: > myfunc()
: Error in sq() : Object "x" not found
:
: I understand that R's scoping rules cause it to look for "x" in the
: environment in which "sq" was defined (the global environment in this case).
: But in this case "x" is defined inside the calling function, not the
: environment in which "sq" was defined.
:
: Is there a way to tell R to look in the calling function for "x" ?
:
: I have tried the following variants of "eval" such as
: eval(sq(),parent.frame()) with no success.
:
Here are two approaches:
1. have myfunc change sq's environment to the current environment:
sq <- function() { y <- x^2; y }
myfunc <- function() { x <- 10; environment(sq) <- environment(); sq() }
myfunc()
2. modify sq itself to get x from the parent frame. We use get in
the example below but you could alternately replace get(...) with
eval.parent(substitute(x)) if you prefer to use eval:
sq <- function() { y <- get("x", parent.frame())^2; y }
myfunc <- function() { x <- 10; sq() }
myfunc()
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] scoping rules
On Thu, 9 Sep 2004 12:01:56 -0400 , Whit Armstrong
<[EMAIL PROTECTED]> wrote :
>Can someone help me with this simple example?
>
>sq <- function() {
> y <- x^2
> y
>}
>
>myfunc <- function() {
> x <- 10
> sq()
>}
>
>myfunc()
>
>
>executing the above in R yields:
>> myfunc()
>Error in sq() : Object "x" not found
>
>I understand that R's scoping rules cause it to look for "x" in the
>environment in which "sq" was defined (the global environment in this case).
>But in this case "x" is defined inside the calling function, not the
>environment in which "sq" was defined.
>
>Is there a way to tell R to look in the calling function for "x" ?
The easiest (and best) is to pass x as an argument to sq.
Duncan Murdoch
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] scoping rules
On Thu, 9 Sep 2004, Whit Armstrong wrote:
Can someone help me with this simple example?
sq <- function() {
y <- x^2
y
}
myfunc <- function() {
x <- 10
sq()
}
myfunc()
executing the above in R yields:
myfunc()
Error in sq() : Object "x" not found
I understand that R's scoping rules cause it to look for "x" in the
environment in which "sq" was defined (the global environment in this case).
But in this case "x" is defined inside the calling function, not the
environment in which "sq" was defined.
Is there a way to tell R to look in the calling function for "x" ?
yes, but you almost certainllyy don't want to.
In a real example you would want to either
1/ Pass x as an argument (most likely)
2/ Define sq() inside myfunc()
3/ define myfunc() inside sq()
4/ Pass the name of x as an argument (eg quote(x) or ~x)
While you can fake dynamic scope in R, there is no point in doing it with
a variable whose name is hard-coded.
The only reason to allow access to a non-local variable x with a fixed
name is to preserve its value across calls to the function, but with
dynamic scope the "x" may be a completely different variable each time.
-thomas
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Re: [R] Scoping rules
It seems like you want in fnB
get(AA$first, envir = parent.frame(1))
but I'm entirely clear on why your original function doesn't work. My
understanding was that get() should search through the parent frames.
-roger
Peter Alspach wrote:
Dear List members:
I'm using R1.7.1 (Windows 2000) and having difficulty with scoping.
I've studied the FAQ and on-line manuals and think I have identified
the
source of my difficulty, but cannot work out the solution.
For the purposes of illustration. I have three functions as defined
below:
fnA <- function(my.x)
{
list(first=as.character(substitute(my.x)), second=sqrt(my.x))
}
fnB <- function(AA)
{
tmp.x <- get(AA$first)
tmp.x^2
}
fnC <- function()
{
x <- 1:2
y <- fnA(x)
z <- fnB(y)
c(x,y,z)
}
fnA() has a vector as an argument and returns the name of the vector
and the square root of its elements in a list. fn(B) takes the result
of fn(A) as its argument, gets the appropriate vector and computes the
square of its elements. These work fine when called at the command
line.
fnC() defines a local vector x and calls fnA() which operates on this
vector. Then fnB() is called, but it operates on a global vector x in
GlobalEnv (or returns an error is x doesn't exist there) - but I want
it
to operate on the local vector.
I think this is related to the enclosing environment of all three
functions being GlobalEnv (since they were created at the command
line),
but the parent environment of fnB() being different when invoked from
within fnC().
My questions:
1 Have I correctly understood the issue ?
2 How do I make fnB() operate on the local vector rather than the
global one ?
3 And, as an aside, I have used as.character(substitute(my.x)) to
pass
the name - but deparse(substitute(my.x)) also works. Is there any
reason to prefer one over the other?
Thank you ...
Peter Alspach
__
The contents of this e-mail are privileged and/or confidential to the
named recipient and are not to be used by any other person and/or
organisation. If you have received this e-mail in error, please notify
the sender and delete all material pertaining to this e-mail.
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
Re: [R] Scoping rules
On Wed, 8 Oct 2003, Roger D. Peng wrote:
> It seems like you want in fnB
>
> get(AA$first, envir = parent.frame(1))
>
> but I'm entirely clear on why your original function doesn't work. My
> understanding was that get() should search through the parent frames.
No, get() searches through the enclosing frames, like ordinary variable
lookup. The only way to get dynamic scope is to specify it explicitly
-thomas
> -roger
>
> Peter Alspach wrote:
> > Dear List members:
> >
> > I'm using R1.7.1 (Windows 2000) and having difficulty with scoping.
> > I've studied the FAQ and on-line manuals and think I have identified
> > the
> > source of my difficulty, but cannot work out the solution.
> >
> > For the purposes of illustration. I have three functions as defined
> > below:
> >
> > fnA <- function(my.x)
> > {
> > list(first=as.character(substitute(my.x)), second=sqrt(my.x))
> > }
> >
> > fnB <- function(AA)
> > {
> > tmp.x <- get(AA$first)
> > tmp.x^2
> > }
> >
> > fnC <- function()
> > {
> > x <- 1:2
> > y <- fnA(x)
> > z <- fnB(y)
> > c(x,y,z)
> > }
> >
> > fnA() has a vector as an argument and returns the name of the vector
> > and the square root of its elements in a list. fn(B) takes the result
> > of fn(A) as its argument, gets the appropriate vector and computes the
> > square of its elements. These work fine when called at the command
> > line.
> >
> > fnC() defines a local vector x and calls fnA() which operates on this
> > vector. Then fnB() is called, but it operates on a global vector x in
> > GlobalEnv (or returns an error is x doesn't exist there) - but I want
> > it
> > to operate on the local vector.
> >
> > I think this is related to the enclosing environment of all three
> > functions being GlobalEnv (since they were created at the command
> > line),
> > but the parent environment of fnB() being different when invoked from
> > within fnC().
> >
> > My questions:
> >
> > 1 Have I correctly understood the issue ?
> > 2 How do I make fnB() operate on the local vector rather than the
> > global one ?
> > 3 And, as an aside, I have used as.character(substitute(my.x)) to
> > pass
> > the name - but deparse(substitute(my.x)) also works. Is there any
> > reason to prefer one over the other?
> >
> > Thank you ...
> >
> >
> > Peter Alspach
> >
> >
> >
> > __
> > The contents of this e-mail are privileged and/or confidential to the
> > named recipient and are not to be used by any other person and/or
> > organisation. If you have received this e-mail in error, please notify
> > the sender and delete all material pertaining to this e-mail.
> >
> > __
> > [EMAIL PROTECTED] mailing list
> > https://www.stat.math.ethz.ch/mailman/listinfo/r-help
> >
>
> __
> [EMAIL PROTECTED] mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-help
>
Thomas Lumley Assoc. Professor, Biostatistics
[EMAIL PROTECTED] University of Washington, Seattle
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
Re: [R] Scoping rules
On Wed, 8 Oct 2003, Roger D. Peng wrote:
> It seems like you want in fnB
>
> get(AA$first, envir = parent.frame(1))
>
> but I'm entirely clear on why your original function doesn't work. My
> understanding was that get() should search through the parent frames.
Where did you get that idea from? Argument `inherits' to get() defaults
to TRUE and is defined as
inherits: should the enclosing frames of the environment be inspected?
Note `enclosing', not `parent'. So the normal R scope rules apply when
looking for an object from the frame of fnB, which as its environment (aka
enclosing frame) is the workspace (.GlobalEnv) is to look in the local
frame and then along the search path.
[This does seem a fairly common misconception, so if you do have any idea
in which document it arises it would be good to know.]
> Peter Alspach wrote:
> > Dear List members:
> >
> > I'm using R1.7.1 (Windows 2000) and having difficulty with scoping.
> > I've studied the FAQ and on-line manuals and think I have identified
> > the
> > source of my difficulty, but cannot work out the solution.
> >
> > For the purposes of illustration. I have three functions as defined
> > below:
> >
> > fnA <- function(my.x)
> > {
> > list(first=as.character(substitute(my.x)), second=sqrt(my.x))
> > }
> >
> > fnB <- function(AA)
> > {
> > tmp.x <- get(AA$first)
> > tmp.x^2
> > }
> >
> > fnC <- function()
> > {
> > x <- 1:2
> > y <- fnA(x)
> > z <- fnB(y)
> > c(x,y,z)
> > }
> >
> > fnA() has a vector as an argument and returns the name of the vector
> > and the square root of its elements in a list. fn(B) takes the result
> > of fn(A) as its argument, gets the appropriate vector and computes the
> > square of its elements. These work fine when called at the command
> > line.
> >
> > fnC() defines a local vector x and calls fnA() which operates on this
> > vector. Then fnB() is called, but it operates on a global vector x in
> > GlobalEnv (or returns an error is x doesn't exist there) - but I want
> > it
> > to operate on the local vector.
I am not sure what you really want to do here, but R works best if you
pass functions an object to work on, and not the name of an object.
Normally this sort of thing is best avoided, but if it is really needed it
is normally simpler to find the object in the calling function (your fnC).
> > I think this is related to the enclosing environment of all three
> > functions being GlobalEnv (since they were created at the command
> > line),
> > but the parent environment of fnB() being different when invoked from
> > within fnC().
> >
> > My questions:
> >
> > 1 Have I correctly understood the issue ?
> > 2 How do I make fnB() operate on the local vector rather than the
> > global one ?
> > 3 And, as an aside, I have used as.character(substitute(my.x)) to
> > pass
> > the name - but deparse(substitute(my.x)) also works. Is there any
> > reason to prefer one over the other?
deparse() is preferred. One subtle reason is what happens with very long
expressions (and note deparse may give more than one line of output),
but the main reason is what happens with expressions such as calls:
> fn1 <- function(x) as.character(substitute(x))
> fn2 <- function(x) deparse(substitute(x))
> fn1(log(x))
[1] "log" "x"
> fn2(log(x))
[1] "log(x)"
It is normally dangerous to use get() on the result of
deparse(substitute()), as the latter may be the character representation
of an expression and not a simple name.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
Re: [R] Scoping rules
I think I misinterpreted this section of the help file for get():
If `inherits' is `FALSE', only the first frame of the specified
environment is inspected. If `inherits' is `TRUE', the search is
continued up through the parent frames until a bound value of the
right mode is found.
Should this read "parent environments" instead of "parent frames"? I'm
taking this from R 1.7.1.
-roger
Prof Brian Ripley wrote:
On Wed, 8 Oct 2003, Roger D. Peng wrote:
It seems like you want in fnB
get(AA$first, envir = parent.frame(1))
but I'm entirely clear on why your original function doesn't work. My
understanding was that get() should search through the parent frames.
Where did you get that idea from? Argument `inherits' to get() defaults
to TRUE and is defined as
inherits: should the enclosing frames of the environment be inspected?
Note `enclosing', not `parent'. So the normal R scope rules apply when
looking for an object from the frame of fnB, which as its environment (aka
enclosing frame) is the workspace (.GlobalEnv) is to look in the local
frame and then along the search path.
[This does seem a fairly common misconception, so if you do have any idea
in which document it arises it would be good to know.]
Peter Alspach wrote:
Dear List members:
I'm using R1.7.1 (Windows 2000) and having difficulty with scoping.
I've studied the FAQ and on-line manuals and think I have identified
the
source of my difficulty, but cannot work out the solution.
For the purposes of illustration. I have three functions as defined
below:
fnA <- function(my.x)
{
list(first=as.character(substitute(my.x)), second=sqrt(my.x))
}
fnB <- function(AA)
{
tmp.x <- get(AA$first)
tmp.x^2
}
fnC <- function()
{
x <- 1:2
y <- fnA(x)
z <- fnB(y)
c(x,y,z)
}
fnA() has a vector as an argument and returns the name of the vector
and the square root of its elements in a list. fn(B) takes the result
of fn(A) as its argument, gets the appropriate vector and computes the
square of its elements. These work fine when called at the command
line.
fnC() defines a local vector x and calls fnA() which operates on this
vector. Then fnB() is called, but it operates on a global vector x in
GlobalEnv (or returns an error is x doesn't exist there) - but I want
it
to operate on the local vector.
I am not sure what you really want to do here, but R works best if you
pass functions an object to work on, and not the name of an object.
Normally this sort of thing is best avoided, but if it is really needed it
is normally simpler to find the object in the calling function (your fnC).
I think this is related to the enclosing environment of all three
functions being GlobalEnv (since they were created at the command
line),
but the parent environment of fnB() being different when invoked from
within fnC().
My questions:
1 Have I correctly understood the issue ?
2 How do I make fnB() operate on the local vector rather than the
global one ?
3 And, as an aside, I have used as.character(substitute(my.x)) to
pass
the name - but deparse(substitute(my.x)) also works. Is there any
reason to prefer one over the other?
deparse() is preferred. One subtle reason is what happens with very long
expressions (and note deparse may give more than one line of output),
but the main reason is what happens with expressions such as calls:
fn1 <- function(x) as.character(substitute(x))
fn2 <- function(x) deparse(substitute(x))
fn1(log(x))
[1] "log" "x"
fn2(log(x))
[1] "log(x)"
It is normally dangerous to use get() on the result of
deparse(substitute()), as the latter may be the character representation
of an expression and not a simple name.
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
Re: [R] Scoping rules
On Wed, 8 Oct 2003, Roger D. Peng wrote:
> I think I misinterpreted this section of the help file for get():
>
> If `inherits' is `FALSE', only the first frame of the specified
> environment is inspected. If `inherits' is `TRUE', the search is
> continued up through the parent frames until a bound value of the
> right mode is found.
>
> Should this read "parent environments" instead of "parent frames"? I'm
> taking this from R 1.7.1.
It should read `enclosing' not `parent' for a start.
Thanks: we will try to get this consistent.
>
> -roger
>
> Prof Brian Ripley wrote:
>
> > On Wed, 8 Oct 2003, Roger D. Peng wrote:
> >
> >
> >>It seems like you want in fnB
> >>
> >>get(AA$first, envir = parent.frame(1))
> >>
> >>but I'm entirely clear on why your original function doesn't work. My
> >>understanding was that get() should search through the parent frames.
> >
> >
> > Where did you get that idea from? Argument `inherits' to get() defaults
> > to TRUE and is defined as
> >
> > inherits: should the enclosing frames of the environment be inspected?
> >
> > Note `enclosing', not `parent'. So the normal R scope rules apply when
> > looking for an object from the frame of fnB, which as its environment (aka
> > enclosing frame) is the workspace (.GlobalEnv) is to look in the local
> > frame and then along the search path.
> >
> > [This does seem a fairly common misconception, so if you do have any idea
> > in which document it arises it would be good to know.]
> >
> >
> >>Peter Alspach wrote:
> >>
> >>>Dear List members:
> >>>
> >>>I'm using R1.7.1 (Windows 2000) and having difficulty with scoping.
> >>>I've studied the FAQ and on-line manuals and think I have identified
> >>>the
> >>>source of my difficulty, but cannot work out the solution.
> >>>
> >>>For the purposes of illustration. I have three functions as defined
> >>>below:
> >>>
> >>>fnA <- function(my.x)
> >>>{
> >>> list(first=as.character(substitute(my.x)), second=sqrt(my.x))
> >>>}
> >>>
> >>>fnB <- function(AA)
> >>>{
> >>> tmp.x <- get(AA$first)
> >>> tmp.x^2
> >>>}
> >>>
> >>>fnC <- function()
> >>>{
> >>> x <- 1:2
> >>> y <- fnA(x)
> >>> z <- fnB(y)
> >>> c(x,y,z)
> >>>}
> >>>
> >>>fnA() has a vector as an argument and returns the name of the vector
> >>>and the square root of its elements in a list. fn(B) takes the result
> >>>of fn(A) as its argument, gets the appropriate vector and computes the
> >>>square of its elements. These work fine when called at the command
> >>>line.
> >>>
> >>>fnC() defines a local vector x and calls fnA() which operates on this
> >>>vector. Then fnB() is called, but it operates on a global vector x in
> >>>GlobalEnv (or returns an error is x doesn't exist there) - but I want
> >>>it
> >>>to operate on the local vector.
> >
> >
> > I am not sure what you really want to do here, but R works best if you
> > pass functions an object to work on, and not the name of an object.
> > Normally this sort of thing is best avoided, but if it is really needed it
> > is normally simpler to find the object in the calling function (your fnC).
> >
> >
> >>>I think this is related to the enclosing environment of all three
> >>>functions being GlobalEnv (since they were created at the command
> >>>line),
> >>>but the parent environment of fnB() being different when invoked from
> >>>within fnC().
> >>>
> >>>My questions:
> >>>
> >>>1 Have I correctly understood the issue ?
> >>>2 How do I make fnB() operate on the local vector rather than the
> >>>global one ?
> >>>3 And, as an aside, I have used as.character(substitute(my.x)) to
> >>>pass
> >>>the name - but deparse(substitute(my.x)) also works. Is there any
> >>>reason to prefer one over the other?
> >
> >
> > deparse() is preferred. One subtle reason is what happens with very long
> > expressions (and note deparse may give more than one line of output),
> > but the main reason is what happens with expressions such as calls:
> >
> >
> >>fn1 <- function(x) as.character(substitute(x))
> >>fn2 <- function(x) deparse(substitute(x))
> >>fn1(log(x))
> >
> > [1] "log" "x"
> >
> >>fn2(log(x))
> >
> > [1] "log(x)"
> >
> >
> > It is normally dangerous to use get() on the result of
> > deparse(substitute()), as the latter may be the character representation
> > of an expression and not a simple name.
> >
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
Re: [R] Scoping rules
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > > Should this read "parent environments" instead of "parent frames"? I'm > > taking this from R 1.7.1. > > It should read `enclosing' not `parent' for a start. > > Thanks: we will try to get this consistent. Beware: Robert has been pretty insistent in using the term "parent environment" for the thing that is ENCLOS() in C code. E.g. we have the functions parent.env() for lexical scope and parent.frame() for dynamic scope. So Roger might well have the better suggestion for achieving consistency. -p -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help
Re: [R] scoping rules
On Sunday 16 March 2003 09:16 pm, Robin Hankin wrote:
> Hi
>
> I recently found a bug that was isomorphic to the following:
>
> ll1 <- 2
> increment <- function(x)
> {
> l11 <- 1
You are not really using this variable (l11, not ll1) anywhere. Is that a
typo? What exactly do you want to happen ?
> return(x+ll1) #bug here
> }
>
> Of course, R is obeying the scoping rules just fine, but I'm evidently
> not setting the do.what.I.mean.not.what.I.say variable correctly.
>
> Now, how do I avoid making this type of error? ... and what is the
> best tool for tracking it down?
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
Re: [R] scoping rules; summary
Robin Hankin wrote:
>
> Hi everyone
>
> thanks for the replies.
>
> The issue was NOT a font problem; I deliberately chose ll1 and l11 as
> examples of easily confused variable names (evidently these were too
> easily confused ;-). The code snippet was written as intended, and
> increment() contained a deliberate, highlighted, bug. I was asking
> for guidance on avoiding/finding this sort of coding error.
>
> That was why I wrote "#bug here" in the original code, and why the
> function was called increment()---because the function should have
> incremented x by adding a variable whose value was 1 (of course, the
> function as written, contrary to the desired functionality of
> increment(), added a variable whose value was 2). I guess I wasn't
> explicit enough here. Sorry.
>
> The fundamental problem was, how to tell that a variable being used in
> a function is not local?
>
> One answer (thanks Patrick!): conflicts() shows masked objects on the
> search path, which is not quite what I need: I want some way to list
> all non-local variables that increment() uses in its body.
>
> [The original variable names referred to genetic bandsharing data for
> possums, eg
>
> coates.female.pouchyoung.allbands.method5
> and
> huapai.young.male.sibling.relatedness.method3
> and
> huapai.old.female.nonsibling.relatedness.justdarkbands.method1
>
> ad nauseum...hence the need for shorter example variable names!]
>
> ll1 <- 2 #sic
> increment <- function(x)
> {
> l11 <- 1#sic
> return(x+ll1) #sic; deliberate bug here (sic)
> }
I think you are looking for ls() together with the debugging tool
browser():
increment <- function(x){
l11 <- 1
browser()# just for debugging
return(x+ll1)
}
increment(1)
# Now the browser opens and you can look for objects in the current
enviroment with ls().
Uwe Ligges
> --
>
> Robin Hankin, Lecturer,
> School of Geography and Environmental Science
> Tamaki Campus
> Private Bag 92019 Auckland
> New Zealand
>
> [EMAIL PROTECTED]
> tel 0064-9-373-7599 x6820; FAX 0064-9-373-7042
>
> __
> [EMAIL PROTECTED] mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-help
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
Re: [R] scoping rules; summary
On Tue, 18 Mar 2003, Robin Hankin wrote:
> Hi everyone
>
> thanks for the replies.
>
> The issue was NOT a font problem; I deliberately chose ll1 and l11 as
> examples of easily confused variable names (evidently these were too
> easily confused ;-). The code snippet was written as intended, and
> increment() contained a deliberate, highlighted, bug. I was asking
> for guidance on avoiding/finding this sort of coding error.
>
> That was why I wrote "#bug here" in the original code, and why the
> function was called increment()---because the function should have
> incremented x by adding a variable whose value was 1 (of course, the
> function as written, contrary to the desired functionality of
> increment(), added a variable whose value was 2). I guess I wasn't
> explicit enough here. Sorry.
>
> The fundamental problem was, how to tell that a variable being used in
> a function is not local?
>
> One answer (thanks Patrick!): conflicts() shows masked objects on the
> search path, which is not quite what I need: I want some way to list
> all non-local variables that increment() uses in its body.
>
>
>
> [The original variable names referred to genetic bandsharing data for
> possums, eg
>
> coates.female.pouchyoung.allbands.method5
> and
> huapai.young.male.sibling.relatedness.method3
> and
> huapai.old.female.nonsibling.relatedness.justdarkbands.method1
>
> ad nauseum...hence the need for shorter example variable names!]
>
>
>
>
> ll1 <- 2 #sic
> increment <- function(x)
> {
> l11 <- 1#sic
> return(x+ll1) #sic; deliberate bug here (sic)
> }
>
I realise this won't help now, but I am currently working on some code
analysis tools for R that will hopefully be available by the end of
summer. These will include facilities for determining what global
variables are references in a piece of code; the current verion of would
does the following on this example:
> findGlobals(increment)
[1] "{" "<-" "return" "+" "ll1"
This set of tools will be integrated with name space mechanism that
will be available in 1.7.0. and will allow packages to be checked for
undefined functions and variables. I suspect these tools will become
part of the tools package.
luke
--
Luke Tierney
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
