[R] scoping rules; summary

[Luke Tierney]

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 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