Re: [Rd] attaching to position 1

From: Martin Maechler <>
Date: Thu 23 Sep 2004 - 17:54:18 EST

>>>>> "PatBurns" == Patrick Burns <> >>>>> on Wed, 22 Sep 2004 18:30:10 +0100 writes:

    PatBurns> If an attempt is made to attach to position 1, it
    PatBurns> appears to work (not even a warning) but in fact
    PatBurns> it doesn't work as many would expect.  "search"
    PatBurns> thinks that it gets placed in position 2, but
    PatBurns> nothing is actually there (according to "ls").

    PatBurns> This is guaranteed to be confusing (and annoying)
    PatBurns> to people who are used to attaching to position 1     PatBurns> in S-PLUS.

yes; thanks for bringing this up!

    PatBurns> I'm not clear on all of the implications of
    PatBurns> changing this, but my first inclination would be
    PatBurns> to make it an error to attach to position 1.  The
    PatBurns> help file says that you can't do it.

and has done so for a long time AFAIR.

    PatBurns> At the very least there should be a warning .  My
    PatBurns> guess is that it is rare for someone to attach to
    PatBurns> position 1 and not attempt to modify what is being
    PatBurns> attached.

Hence (together with the arguments further above), I think an error would be more appropriate [if there's only a warning and the user's code continues on  the wrong assumption, more problems lay ahead].

OTOH, in the current "beta" phase I can think of a case where an error would be too "hard":
The worst I can see is an R script that has attach(*, pos=1) which doesn't attach at all {as you say, it *seems* to attach to position 2 but doesn't really provide the object}, but for some reason still continues to produce reasonable things.

Hene, for 2.0.0 in "deep freeze", I'd propose to give a warning only. However, we wouldn't the database' to search()[2] "seemingly" only, and this could be a problem if a user's script does a detach(..) later. I.e., we should attach() to pos=2 *properly* (instead of "seemingly") only.

At the latest for 2.1.0, we should rather make the warning an error.

In any case, this looks like a very simple fix (to the C source);

Martin Maechler

>> attach('foo.RData')
>> search()

    PatBurns> [1] ".GlobalEnv"        "file:foo.RData"    "package:methods" 
    PatBurns> [4] "package:stats"     "package:graphics"  "package:grDevices"
    PatBurns> [7] "package:utils"     "package:datasets"  "Autoloads"       
    PatBurns> [10] "package:base"    

>> ls(2)

    PatBurns> [1] "jj"
>> jj

    PatBurns> [1] 1 2 3 4 5 6 7 8 9
>> detach()
>> search()
    PatBurns> [1] ".GlobalEnv"        "package:methods"   "package:stats"   
    PatBurns> [4] "package:graphics"  "package:grDevices" "package:utils"   
    PatBurns> [7] "package:datasets"  "Autoloads"         "package:base"    

>> attach('foo.RData', pos=1)
>> search()
    PatBurns> [1] ".GlobalEnv"        "file:foo.RData"    "package:methods" 
    PatBurns> [4] "package:stats"     "package:graphics"  "package:grDevices"
    PatBurns> [7] "package:utils"     "package:datasets"  "Autoloads"       
    PatBurns> [10] "package:base"    

>> ls(2)

    PatBurns> character(0)
    PatBurns> _                          
    PatBurns> platform i386-pc-mingw32            
    PatBurns> arch     i386                       
    PatBurns> os       mingw32                    
    PatBurns> system   i386, mingw32              
    PatBurns> status   Under development (unstable)
    PatBurns> major    2                          
    PatBurns> minor    0.0                        
    PatBurns> year     2004                       
    PatBurns> month    09                         
    PatBurns> day      17                         
    PatBurns> language R

______________________________________________ mailing list Received on Thu Sep 23 17:58:51 2004

This archive was generated by hypermail 2.1.8 : Wed 03 Nov 2004 - 22:45:17 EST