On Tue, Mar 6, 2012 at 11:44 AM, William Dunlap <wdun...@tibco.com> wrote: > S (and its derivatives and successors) promises that functions > will not change their arguments, so in an expression like > val <- func(arg) > you know that arg will not be changed. You can > do that by having func copy arg before doing anything, > but that uses space and time that you want to conserve. > If arg is not a named item in any environment then it > should be fine to write over the original because there > is no way the caller can detect that shortcut. E.g., in > cx <- cos(runif(n)) > the cos function does not need to allocate new space for > its output, it can just write over its input because, without > a name attached to it, the caller has no way of looking > at what runif(n) returned. If you did > x <- runif(n) > cx <- cos(x) > then cos would have to allocate new space for its output > because overwriting its input would affect a subsequent > sum(x) > I suppose that end-users and function-writers could learn > to live with having to decide when to copy, but not having > to make that decision makes S more pleasant (and safer) to use. > I think that is a major reason that people are able to > share S code so easily.
But don't forget the "Holy Grail" that Doug mentioned at the start of this thread: finding a flexible language that is also fast. Currently many R packages employ C/C++ components to compensate for the fact that the R interpreter can be slow, and the pass-by-value semantics of S provides no protection here. In 2008 Ross Ihaka and Duncan Temple Lang published the paper "Back to the Future: Lisp as a base for a statistical computing system" where they propose Common Lisp as a new foundation for R. They suggest that this could be done while maintaining the same familiar R syntax. A key requirement of any strategy is to maintain easy access to the huge universe of existing C/C++/Fortran numerical and graphics libraries, as these libraries are not likely to be rewritten. Thus there will always be a need for a foreign function interface, and the problem is to provide a flexible and type-safe language that does not force developers to use another unfamiliar, less flexible, and error-prone language to optimize the hot spots. Dominick > Bill Dunlap > Spotfire, TIBCO Software > wdunlap tibco.com > >> -----Original Message----- >> From: oliver [mailto:oli...@first.in-berlin.de] >> Sent: Tuesday, March 06, 2012 1:12 AM >> To: William Dunlap >> Cc: Hervé Pagès; R-devel >> Subject: Re: [Rd] Julia >> >> On Tue, Mar 06, 2012 at 12:35:32AM +0000, William Dunlap wrote: >> [...] >> > I find R's (& S+'s & S's) >> > copy-on-write-if-not-copying-would-be-discoverable- >> > by-the-uer machanism for giving the allusion of pass-by-value a good way >> > to structure the contract between the function writer and the function >> > user. >> [...] >> >> >> Can you elaborate more on this, >> especially on the ...-...-...-if-not-copying-would-be-discoverable-by-the-uer >> stuff? >> >> What do you mean with discoverability of not-copying? >> >> Ciao, >> Oliver > ______________________________________________ > 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
