[Rd] Question on an alternative to ls() and expanded R object types

[Adrian Vance Custer]

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