R devel - Jun 2000 - Question on an alternative to ls() and expanded R object types

> suggestions into the user documentation. Perhaps these issues only affect
> me, or affect everyone but are huge coding efforts. I suspect getting color
Well, these issues don't affect me at all. (You said you wanted feedback).

Bill

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

Hello everyone,

This question and associated comments come from a desire for more sanity in
my object name space. These ideas may just be a whacky, way too difficult
to implement or already possible with existing functions.


Would it be possible to improve R's listing ability by adding the capability
to list objects by type, creation date, modification date, ancestry and/or
user comments?


Right now my object names are devoted to keeping track of these issues
rather gouping objects by subject. My object names have their types either as
prefixes or suffixes and my name space is structured whith A.~~ as storage
space, f.~~ as functions, p.~~ as plot scripts and working.~~ or z.~~ as
working.data. Then I use dummy variables, for instance, fxxxxxxxxxxxxxxxxxx~
to delimit the space between functions and plots. This is all done so that
ls() returns a well structured workspace. Note that my only organizational
structure is the alphbetical nature of the objects rather than object
attributes. Splus has solved these issues with the object browser which is
complex and non-intuitive. While eventually such a system could be created,
it is a large project.

ls() returns a vector of names which is useful for language constructs
(functions that might manipulate the listing) but perhaps less useful for
interactive use. It would be neat to be able to get a colorized list of
object names with colors assigned to object type. This would,of course,
require a color terminal. Alternatively, the listing could return a list
of name vectors for different types so that I could say, newls()$vectors,
and get the vectors. I've started working on something like this but it
has the look and feel of someone largely unfamiliar with the subtleties of
the language. (Note typeof(), and thereby mode(), does not differentiate
between lists and frames.)

Another luxury would be able to list the objects I've played with in the
past few days. Since this facility doesn't exist I have to be exceedingly
careful to remember the objects I have worked with recently. Similarly,
when I derive an object from another, I currently have to remember the
hierarchy. I am working mostly from a single large frame from which I
extract various pieces. I modify these pieces to attempt an analysis or
another but I must track both the objects and subobjects and the operations
that happened along the way. I envison something like the call object in
the model objects.  I suspect adding to each object its ancestry would
take up a fair amount of space but I have no real sense of the memory
requirements of such an addition.

The idea of a comment space may suffer similar difficulties of storage. I
sometime could use the ability to do
> z.vec.log.tsetse_(A.FRAME.tsela.300.cont$logtse,comment="First six
samples")
so that the name space does not have to hold all the clues about the
object itself.

The newls() function I discuss earlier is implementable in
userspace. However, the other issues are not. I would be interested
to read your responses. Perhaps these issues can be solved with better
organization. If that is the case, I would like the learn this and get these
suggestions into the user documentation. Perhaps these issues only affect
me, or affect everyone but are huge coding efforts. I suspect getting color
into the terminal would be a large effort. Similarly, expanding the base
object with object histories, times and comments may be too much work. If I
remember correctly, there is a substantial difference between Splus5 objects
and earlier types which may be relevant to the ability to do such things.

Thank you for any responses,

adrian
acuster@nature.berkeley.edu


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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, 29 Jun 2000, Adrian Vance Custer wrote:
> 
> Would it be possible to improve R's listing ability by adding the
capability
> to list objects by type, creation date, modification date, ancestry and/or
> user comments?
As you point out, the listing by type could be done in userspace.  The
comments could also be done this way, and you could add creation and
modification dates by hand this way or with simple functions like the
following, which adds a comment and the date it was made

addComment<-function(x,commment){
	cc<-attr(x,"comment")
	if (is.null(cc))
	    cc<-list()
	cc[[length(cc)+1]]<-paste(comment,date)
	attr(x,"comment")<-cc	
	x
	}	

showComments<-function(x){
	cc<-attr(x,"comment")
	if (is.null(cc)) 
	   return("No Comment")
        else
	   cc
	}
 
> Another luxury would be able to list the objects I've played with in
the
> past few days. Since this facility doesn't exist I have to be
exceedingly
> careful to remember the objects I have worked with recently. Similarly,
> when I derive an object from another, I currently have to remember the
> hierarchy. I am working mostly from a single large frame from which I
> extract various pieces. I modify these pieces to attempt an analysis or
> another but I must track both the objects and subobjects and the operations
> that happened along the way. I envison something like the call object in
> the model objects.  I suspect adding to each object its ancestry would
> take up a fair amount of space but I have no real sense of the memory
> requirements of such an addition.
The problem here is not so much the space, since Unix time and date
information can be stored in 32 bits (at least until 2038), but the
time.  Adding a creation time to every object would probably have serious
effects on the speed of R (in addition to the amount of work it would
take to implement). That's why it's probably better to just use
comments.

Storing a pointer to the parents of an object would be a real pain (since
it would require keeping track of what objects were evaluated to do each
modification) and to do it properly would require keeping old versions of
the objects.

Something less general but more useful is probably to keep ESS transcripts
of sessions, which can then be replayed if the data changes. Some R
developers and others are interested in this sort of idea as 'Literate
Data Analysis' by analogy with Literate Programming.

	-thomas

Thomas Lumley
Assistant Professor, Biostatistics
University of Washington, Seattle

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