hadley wickham wrote:
>>> Providing the ability to write assignment functions that don't duplicate
>>> is a more urgent problem.
>>>       
>> You mean, for end-users?  It can be done via primitives.
>>     
>
> Isn't this sort of a run-time optimisation?  I thought R generally
> followed the functional programming model of immutable objects, copy
> on modification.
>   
Indeed, and the concept that objects, rather than object references, are 
passed as arguments is one we should be careful to preserve.

Assignment functions (or replacement functions, if that's what we're 
talking about) do not violate that concept, because they compute a 
replacement for the object which is then re-assigned; e.g.,
 foo(x) <- bar
is really
 x <- "foo<-"(x, bar)
and we should NOT violate that concept just for some efficiency 
argument.  In C code  a CAREFUL examination of  arguments may show that 
duplication can be avoided without disaster, but each such piece of code 
potentially lessens the trust one can have in the computation.
> As a general comment/question - it seems to me the R seems to be
> moving away from a functional paradigm to be more OO (especially among
> package developers).
>   
Well, it depends which part of the elephant you are touching.  Methods 
and classes are examples of a functional-class-based language, of which 
there are a few others (Dylan, e.g.).  I would distinguish that from 
what I would call class-based OOP languages such as C++ and Java.

It's true that methods change the evaluation model somewhat.  In 
particular, arguments involved in method dispatch have to be evaluated 
for dispatch (though missing arguments can just be "missing"), so lazy 
evaluation is compromised for those arguments.  Otherwise, the semantics 
of function calls remains largely unaltered.

A different discussion is the desire to pass object references in R.  
There are in fact objects that currently act as references, notably 
environments.  If one wants to, a general reference-semantic set of 
capabilities can be added to R, either on that basis or otherwise.  It's 
potentially a useful thing to do and several people have played around 
with it.  It is NOT an argument for changing the semantics of existing 
classes of objects, IMO.
>   
>> As I said in my reply on R-help, I don't see the original as at all a
>> common problem.  About the only times where a bound on number of entries
>> is unknown in advance is when reading from a connection (and there the
>> internal code does uses doubling strategies), and in a iterative procedure
>> with no limit on the number of iterations (not usually good practice).
>>     
>
> Agreed - but it is a very common mistake, and this change could bring
> large performance increases to any written in this way.  Of course,
> you can only protect users from themselves to some extent, and I can
> imagine many things that would be both more interesting to work on and
> provide performance benefits for people who understand more about how
> vectors work.
>
> Regards,
>
> Hadley
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>   

	[[alternative HTML version deleted]]

