[Rd] attaching to position 1

[Martin Maechler]

>>>>> "PatBurns" == Patrick Burns <pburns at pburns.seanet.com>
>>>>>     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