Julia
On Tue, Mar 06, 2012 at 12:49:32PM -0500, Dominick Samperi wrote:
On Tue, Mar 6, 2012 at 11:44 AM, William Dunlap <wdunlap at 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)
You have two names here, x and cx, hence your example does not fit into what you want to explain. A better example would be: x <- runif(n) x <- 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.
[...] The distinction imperative vs. functional has nothing to do with the distinction interpreted vs. directly executed. Thinking again on the problem that was mentioned here, I think it might be circumvented. Looking again at R's properties, looking again into U.Ligges "Programmieren in R", I saw there was mentioned that in R anything (?!) is an object... so then it's OOP; but also it was mentioned, R is a functional language. But this does not mean it's purely functional or has no imperative data structures. As R relies heavily on vectors, here we have an imperative datastructure. So, it rather looks to me that "<-" does work in-place on the vectors, even "<-" itself is a function (which does not matter for the problem). If thats true (I assume here, it is; correct me, if it's wrong), then I think, assigning with "<<-" and assign() also would do an imperative (in-place) change of the contents. Then the copying-of-big-objects-when-passed-as-args problem can be circumvented by working on either a variable in the GlobalEnv (and using "<<-", or using a certain environment for the big data and passing it's name (and the variable) as value to the function which then uses assign() and get() to work on that data. Then in-place modification should be possible.
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.
If I here "type safe" I rather would think about OCaml
or maybe Ada, but not LISP.
Also, LISP has so many "("'s and ")"'s,
that it's making people going crazy ;-)
Ciao,
Oliver