On Sat, Mar 7, 2009 at 3:19 PM, Wacek Kusnierczyk <waclaw.marcin.kusnierc...@idi.ntnu.no> wrote: > Gabor Grothendieck wrote: >> >> I've provided an argument against it and no one has provided one >> for it. The so-called identical code Ivo showed was not identical >> and, in fact, was flawed. > > no, you're wrong. you think of the part where ivo shows what he'd like > to have; the example i was referring to was almost identical with > yours, except for the explicit return and '=' used for assignment. > > >> Your first/last example could be >> written: >> >> f <- function() letters >> L <- structure(f()[1:2], names = c("first", "last")) >> > > indeed, but: > > - this still does not allow one to use the names directly, only as > L$first etc., with the syntactic and semantic (longer lookup times) penalty;
That's how it should be done. Using the auto split you get many variables which is not desirable. it encourages bad programming. > > - using structure you add yet another source of performance penalty; a > quick naive benchmark hints that it doubles the time elapsed if the > returned list is inaccessible otherwise, and adds one order of magnitude > if the list has to be copied: There is no difference between structure and assignment. They are both operations. If there is a timing difference that is a different question. > > f1= function() as.list(letters) > f2 =local({ letters = as.list(letters); function() letters }) > > source('http://rbenchmark.googlecode.com/svn/trunk/benchmark.r') > benchmark(replications=10000, columns=c('test', 'elapsed'), > 'f1 direct'=f1(), > 'f1 structure'=structure(f1(), names=letters), > 'f2 direct'=f2(), > 'f2 structure'=structure(f2(), names=letters)) > > # test elapsed > # 1 f1 direct 0.171 > # 2 f1 structure 0.693 > # 3 f2 direct 0.048 > # 4 f2 structure 0.594 > > instead of a syntactically (and semantically, if done appropriately) > clean solution: > > c(a, b) = f()[1,3] > # work with a and b > > you offer a glut: > > l = structure(f()[1,3], names=c('a', 'b')) > # work with l$a and l$b > > >> or one could define a function to do that without having >> to modify the language. Given the relative infrequency >> of this it hardly seems to merit a language feature. >> > > infrequency of what? of people's inventing ugly hacks to get arround > the inability to capture multiple return values directly? sure, this is > a good argument against having someone do the job, but is it a good > argument against having the feature in the language? I have never had to use it even though I had it available for years. I do lots of R code so I think it speaks for itself. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel