From djsamperi at gmail.com  Tue Mar  6 18:49:32 2012
From: djsamperi at gmail.com (Dominick Samperi)
Date: Tue, 6 Mar 2012 12:49:32 -0500
Subject: [Rd] Julia
In-Reply-To: <E66794E69CFDE04D9A70842786030B932834C7@PA-MBX04.na.tibco.com>
References: <CAO7JsnRykFo22Jc+pTGsZhg9EvFE=zxE3XpVvSnzc-=mp=AfKw@mail.gmail.com>
	<20120303011413.GA18995@siouxsie>
	<E66794E69CFDE04D9A70842786030B93282DF1@PA-MBX04.na.tibco.com>
	<20120305170835.GA4134@siouxsie> <4F555343.8020007@fhcrc.org>
	<E66794E69CFDE04D9A70842786030B932831A9@PA-MBX04.na.tibco.com>
	<20120306091143.GC1849@siouxsie>
	<E66794E69CFDE04D9A70842786030B932834C7@PA-MBX04.na.tibco.com>
Message-ID: <CADUbQ5j-d2EcaqNU1cQN3SEEheF7YB+KV0==4iu8XkQbbytCnw@mail.gmail.com>

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



[Rd] Julia
Dominick Samperi