Re: [Rd] Julia

From: Dominick Samperi <>
Date: Tue, 06 Mar 2012 12:49:32 -0500

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)
> 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.


> Bill Dunlap
> Spotfire, TIBCO Software
> wdunlap
>> -----Original Message-----
>> From: oliver []
>> 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
> ______________________________________________
> mailing list
> mailing list Received on Tue 06 Mar 2012 - 17:56:16 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 - 19:20:28 GMT.

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

list of date sections of archive