1) I have been working on making R libraries more like those in S.
I thought it might be advisable to discuss the ideas before springing
them on you. What I have done is changed things so that each library
has its own frame on the search path. E.g.
> search()
[1] ".GlobalEnv" "library:base"
> library("eda")
> search()
[1] ".GlobalEnv" "library:eda" "library:base"
> ls(pos=2)
[1] "coefficients.tukeyline" "fitted.values.tukeyline"
[3] "line" "medpolish"
[5] "plot.medpolish" "print.medpolish"
[7] "print.tukeyline" "residuals.tukeyline"
[9] "smooth"
> assign("x", 10, pos=2)
> ls(pos=2)
[1] "coefficients.tukeyline" "fitted.values.tukeyline"
[3] "line" "medpolish"
[5] "plot.medpolish" "print.medpolish"
[7] "print.tukeyline" "residuals.tukeyline"
[9] "smooth" "x"
All the search-path aware functions (ls, objects, assign, get, rm,
etc) now have a pos= argument which can be used to specify a frame to
work on.
I have not given S style path-names to the source of the libraries
because libraries are really internal objects rather than external
directories.
Libraries will have a .First and .Last functions.
I have not done anything about name-space clutter, but I have a couple
of ideas on name hiding which might be possible ( basically, every
library would have to "export" the names it wanted to be visible to
users).
I have not decided whether the user's global environment could be
detached or whether libraries or data objects could be attached before
it on the search path.
2) I am going ahead with implementing saving and restoring of data in
XDR format, so that there will be less trouble with heterogeneous Unix
networks. Because the format of saved files will change, we must
either be incompatible or have some mechanism for restoring old save
files. I would rather avoid the compatibility route if possible.
Would anyone be seriously inconvenienced if old data files could not
be restored? (Its not hard to build in compatibility, it would just
take time which could be spend elsewhere).
Ross
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Ross Ihaka <ihaka@stat.auckland.ac.nz> writes:> Would anyone be seriously inconvenienced if old data files could not > be restored? (Its not hard to build in compatibility, it would just > take time which could be spend elsewhere).I think the time would be well spent. Of course few people as of now will have important data (only) in .RData format, and those that do are probably clueful enough to save them in portable format before upgrading. That situation won't last long, I suspect, (perhaps student labs are *already* a problem?) and this might not be the last change of the file format, so making sure that the program structure allows loading of different file format revisions is likely to be useful anyway. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
On Thu, 15 May 1997, Ross Ihaka wrote:> I have not done anything about name-space clutter, but I have a couple > of ideas on name hiding which might be possible ( basically, every > library would have to "export" the names it wanted to be visible to > users).This is certainly nice in principle, though not tremendously important at the moment. It would be convenient to be able to declare functions in a library that are global to the library but not accessible to the outside world.> 2) I am going ahead with implementing saving and restoring of data in > XDR format, so that there will be less trouble with heterogeneous Unix > networks. Because the format of saved files will change, we must > either be incompatible or have some mechanism for restoring old save > files. I would rather avoid the compatibility route if possible. > Would anyone be seriously inconvenienced if old data files could not > be restored? (Its not hard to build in compatibility, it would just > take time which could be spend elsewhere).For my purposes dump() will work fine for transferring old data files. Will the changes give cross-platform (Mac/Win) portability too? Thomas Lumley ------------------------------------------------------+------ Biostatistics : "Never attribute to malice what : Uni of Washington : can be adequately explained by : Box 357232 : incompetence" - Hanlon's Razor : Seattle WA 98195-7232 : : ------------------------------------------------------------ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > I have not done anything about name-space clutter, but I have a couple > > of ideas on name hiding which might be possible ( basically, every > > library would have to "export" the names it wanted to be visible to > > users).> This is certainly nice in principle, though not tremendously important at > the moment. It would be convenient to be able to declare functions in a > library that are global to the library but not accessible to the outside > world.This is what I had in mind. The functions in the library (and those exported) could see all functions and data in the library, but only the exported objects would be visible globally. Of course, R scoping can be used to provide this kind privacy, but you have to think about setting up the libraries more carefully.> > 2) I am going ahead with implementing saving and restoring of data in > > XDR format, so that there will be less trouble with heterogeneous Unix > > networks. Because the format of saved files will change, we must > > either be incompatible or have some mechanism for restoring old save > > files. I would rather avoid the compatibility route if possible. > > Would anyone be seriously inconvenienced if old data files could not > > be restored? (Its not hard to build in compatibility, it would just > > take time which could be spend elsewhere).> For my purposes dump() will work fine for transferring old data files.> Will the changes give cross-platform (Mac/Win) portability too?This will depend on the availability of the XDR library for those platforms. I seem to recall that XDR is available for Windows at least. I'm rather more concerned with Unix because it is common to have a mix of platforms accessing the same data under Unix. Ross =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>1) I have been working on making R libraries more like those in S....> > library("eda") > > search() > [1] ".GlobalEnv" "library:eda" "library:base"As I recall in S, library() adds to the end of the search list unless First=T is specified. The function attach() works by putting things in position 2.>Libraries will have a .First and .Last functions.As I recall these are called .First.lib and .Last.lib in S.>I have not done anything about name-space clutter, but I have a couple >of ideas on name hiding which might be possible ( basically, every >library would have to "export" the names it wanted to be visible to >users).In theory this is probably the preferred way to do this, but I think compatability with S may be more easily maintained if you explicitly hide names which can be hidden. ...>Would anyone be seriously inconvenienced if old data files could not >be restored?This is not a problem for me. However, if you do it, a separate conversion utility might be better as it is something for which there will eventually be no need. Also, on XDR, I took a quick scan through the Bank of Canada PADI code which uses XDR, just to see if there might be any helpful hints. I didn't find too much, but there where a number of comments about "deleting NULL pointers so that XDR does not barf," for what that's worth. Good luck. Paul Gilbert P.S. 0.49 with patch2a seems to be working really well. The most serious problem for my time series library is now eigen() for non-symmetric matrices. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-