I think that the "sorted" and "all.names" arguments are really only appropriate for pretty printing to the screen. I think it is a bit unfortunate that environments have a names accessor that is 60X slower than all the other types. This is likely due to the history of environments, which were originally just for behind-the-scenes tasks.
Now that users can use environments as hashes, we really need something like a "keys" function. We don't want programmers depending on the sorted-ness, as Martin mentioned. Also, I think it helps users when objects share as many of the key API functions as possible. "names" is natural. "ls" was certainly confusing for me when I started. Having to supply two additional arguments to get the desired output doesn't help there. Think of all the perl programmers struggling to switch to R. Let's help them out. Pete ____________________ Peter M. Haverty, Ph.D. Genentech, Inc. phave...@gene.com On Tue, Jan 27, 2015 at 7:26 AM, Michael Lawrence <lawrence.mich...@gene.com> wrote: > I think ls(, sort=FALSE) would be more explicit and thus clearer. There is > much precedent for having arguments that request less work to be done e.g. > unlist(use.names=FALSE). Yes, the extra typing is a bit painful, but there > is no intuitive reason why names() would be unsorted, while ls() would be > sorted. While it is tempting to use an existing function for this, the word > "names" is somewhat loaded. For example, one might expect > identical(names(env), names(as.list(env))) to be TRUE. I see no problem with > making names() a simple alias of ls(), as long as the behavior is the same. > Maybe a different name would be less "loaded" and imply lack of order, > something like keySet(). But do we really need this? > > > > > > > On Tue, Jan 27, 2015 at 7:11 AM, Martin Maechler > <maech...@lynne.stat.math.ethz.ch> wrote: >> >> >>>>> Peter Haverty <haverty.pe...@gene.com> >> >>>>> on Sun, 25 Jan 2015 12:21:04 -0800 writes: >> >> > Hi all, >> > The "ls" function wears two hats. It allows users to inspect an >> > environment interactively and also serves deeper in code as the >> > accessor for an environment's names/keys. I propose that we separate >> > these two conflicting goals, keeping ls for interactive use and >> adding >> > names for a quick listing of the hash keys. This involves adding two >> > lines to do_names in attrib.c. >> >> > The 'ls' function and its 'objects' synonym appear very frequently >> in >> > performance-critical code like base/R/namespace.R and throughout the >> > methods package. These functions are currently among the major >> > contributors to execution time in package loading. >> >> > This two-line addition to attrib.c gives a significant speedup for >> > listing an environment's names/keys (2-60X depending on the 'sorted' >> > argument). It also simplifies the environment API by making it more >> > like the other basic types. We already have $ and [[ after all. >> >> > Rather than sprinkling sorted=FALSE throughout the methods and base >> > code, let's use names. >> >> as for list()s and other (generalized) vectors. >> >> This sounds appealing at first, and I have heard/seen others propose >> it. I see one good reason *not* to allow it (and you mention the >> reason by mentioning 'sorted') : >> >> The contents of an environment are inherently unordered, and >> even if the order stays fixed for a while, no code should rely >> on the ordering of the objects, and for that reason, >> <env>[1] etc do not make sense and are not allowed. >> >> > Would you be open to this change? >> >> I'm undecided currently: >> "-": reason above; >> "+": convenience, compacter R code using it; >> very simple and natural change to src/main/attrib.c >> >> and waiting for other comments, not the least from other members of R core >> .. >> >> Martin Maechler, ETH Zurich >> >> >> > I have submitted a patch and some timings to the bug tracker as >> > https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16170 >> >> > Regards, >> > Pete >> >> > ____________________ >> > Peter M. Haverty, Ph.D. >> > Genentech, Inc. >> > phave...@gene.com >> >> > ______________________________________________ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
