hadley wickham wrote: >>> Providing the ability to write assignment functions that don't duplicate >>> is a more urgent problem. >>> >> You mean, for end-users? It can be done via primitives. >> > > Isn't this sort of a run-time optimisation? I thought R generally > followed the functional programming model of immutable objects, copy > on modification. > Indeed, and the concept that objects, rather than object references, are passed as arguments is one we should be careful to preserve.
Assignment functions (or replacement functions, if that's what we're talking about) do not violate that concept, because they compute a replacement for the object which is then re-assigned; e.g., foo(x) <- bar is really x <- "foo<-"(x, bar) and we should NOT violate that concept just for some efficiency argument. In C code a CAREFUL examination of arguments may show that duplication can be avoided without disaster, but each such piece of code potentially lessens the trust one can have in the computation. > As a general comment/question - it seems to me the R seems to be > moving away from a functional paradigm to be more OO (especially among > package developers). > Well, it depends which part of the elephant you are touching. Methods and classes are examples of a functional-class-based language, of which there are a few others (Dylan, e.g.). I would distinguish that from what I would call class-based OOP languages such as C++ and Java. It's true that methods change the evaluation model somewhat. In particular, arguments involved in method dispatch have to be evaluated for dispatch (though missing arguments can just be "missing"), so lazy evaluation is compromised for those arguments. Otherwise, the semantics of function calls remains largely unaltered. A different discussion is the desire to pass object references in R. There are in fact objects that currently act as references, notably environments. If one wants to, a general reference-semantic set of capabilities can be added to R, either on that basis or otherwise. It's potentially a useful thing to do and several people have played around with it. It is NOT an argument for changing the semantics of existing classes of objects, IMO. > >> As I said in my reply on R-help, I don't see the original as at all a >> common problem. About the only times where a bound on number of entries >> is unknown in advance is when reading from a connection (and there the >> internal code does uses doubling strategies), and in a iterative procedure >> with no limit on the number of iterations (not usually good practice). >> > > Agreed - but it is a very common mistake, and this change could bring > large performance increases to any written in this way. Of course, > you can only protect users from themselves to some extent, and I can > imagine many things that would be both more interesting to work on and > provide performance benefits for people who understand more about how > vectors work. > > Regards, > > Hadley > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
