Re: [Rd] Julia

From: oliver <>
Date: Wed, 07 Mar 2012 19:21:39 +0100

On Tue, Mar 06, 2012 at 12:49:32PM -0500, Dominick Samperi wrote:
> On Tue, Mar 6, 2012 at 11:44 AM, William Dunlap <> 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 ;-)


   Oliver mailing list Received on Wed 07 Mar 2012 - 18:30:03 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Wed 07 Mar 2012 - 23:40:28 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive