No my examples are what I meant. My point was that a function, say cos(),
can act like it does call-by-value but conserve memory when it can if it can
distinguish between the case
cx <- cos(x=runif(n)) # no allocation needed, use the input space for the
return value
and and the case
x <- runif(n)
cx <- cos(x=x) # return value cannot reuse the argument's memory, so
allocate space for return value
sum(x) # Otherwise sum(x) would return sum(cx)
The function needs to know if a memory block is referred to by a name in any
environment
in order to do that.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
> -----Original Message-----
> From: oliver [mailto:oli...@first.in-berlin.de]
> Sent: Wednesday, March 07, 2012 10:22 AM
> To: Dominick Samperi
> Cc: William Dunlap; R-devel
> Subject: Re: [Rd] 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 <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)
>
> 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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
