From Waclaw.Marcin.Kusnierczyk at idi.ntnu.no  Sat Mar  7 22:13:12 2009
From: Waclaw.Marcin.Kusnierczyk at idi.ntnu.no (Wacek Kusnierczyk)
Date: Sat, 07 Mar 2009 22:13:12 +0100
Subject: [Rd] question
In-Reply-To: <971536df0903071303j2cf200a7i88185a75c4a3985d@mail.gmail.com>
References: <000325575fc2f3201e046488263f@google.com>	
	<49B29233.7040205@idi.ntnu.no>	
	<971536df0903070806g38eee325q2e0cc5f2da8141b4@mail.gmail.com>	
	<49B2A2E1.20508@idi.ntnu.no>	
	<971536df0903070846h3692e809ga195d126da37de5e@mail.gmail.com>	
	<49B2D6EA.4080907@idi.ntnu.no>
	<971536df0903071303j2cf200a7i88185a75c4a3985d@mail.gmail.com>
Message-ID: <49B2E368.3020505@idi.ntnu.no>

Gabor Grothendieck wrote:
>
>> - this still does not allow one to use the names directly, only as
>> L$first etc., with the syntactic and semantic (longer lookup times) penalty;
>>     
>
> That's how it should be done. Using the auto split you get many
> variables which is not desirable.  it encourages bad programming.
>
>   

please provide a reference for this claim.  for both the 'should' and
the 'bad'.

>> - using structure you add yet another source of performance penalty; a
>> quick naive benchmark hints that it doubles the time elapsed if the
>> returned list is inaccessible otherwise, and adds one order of magnitude
>> if the list has to be copied:
>>     
>
> There is no difference between structure and assignment. They are both
> operations.  If there is a timing difference that is a different question.
>   

as far as i get the r semantics, applying structure modifies the object,
and causes the content to be copied if the object is referred to from
elsewhere.  here's where structure does add a considerable performance
penalty.


>
>>> or one could define a function to do that without having
>>> to modify the language.   Given the relative infrequency
>>> of this it hardly seems to merit a language feature.
>>>
>>>       
>> infrequency of what?  of people's inventing ugly hacks to get arround
>> the inability to capture multiple return values directly?  sure, this is
>> a good argument against having someone do the job, but is it a good
>> argument against having the feature in the language?
>>     
>
> I have never had to use it even though I had it available for years.
> I do lots of R code so I think it speaks for itself.
>   

it speaks for yourself.  it tells nothing about what others would like. 
it's quite possible that few would like it, but it does not follow from
that you wouldn't.

vQ



[Rd] question
Wacek Kusnierczyk