oliver at first.in-berlin.de
Wed Mar 7 19:21:39 CET 2012
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
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
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
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 ;-)
More information about the R-devel