[Rd] Julia

[Dominick Samperi]

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

Dominick

> Bill Dunlap
> Spotfire, TIBCO Software
> wdunlap tibco.com
>
>> -----Original Message-----
>> From: oliver [mailto:oliver at first.in-berlin.de]
>> 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
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel