From murdoch at stats.uwo.ca  Tue Jan  2 02:44:40 2007
From: murdoch at stats.uwo.ca (Duncan Murdoch)
Date: Mon, 01 Jan 2007 20:44:40 -0500
Subject: [Rd] Wish list
In-Reply-To: <59d7961d0701011735l187466c2v60a32576f35ef2e3@mail.gmail.com>
References: <971536df0612312228i4a4bb0b2h6c52c081213c296@mail.gmail.com>	
	<45993282.7030409@stats.uwo.ca>	
	<Pine.LNX.4.64.0701010946250.6276@tajo.ucsd.edu>	
	<4599A81D.6050202@stats.uwo.ca>
	<59d7961d0701011735l187466c2v60a32576f35ef2e3@mail.gmail.com>
Message-ID: <4599B908.3060509@stats.uwo.ca>

Henrik Bengtsson wrote:
> On 1/2/07, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
>   
>> On 1/1/2007 12:59 PM, Charles C. Berry wrote:
>>     
>>> On Mon, 1 Jan 2007, Duncan Murdoch wrote:
>>>
>>>       
>>>> A few comments thrown in, and some general comments at the bottom.
>>>>
>>>> On 1/1/2007 1:28 AM, Gabor Grothendieck wrote:
>>>>         
>>>>> This is my 2007 New Year wishlist for R features:
>>>>>
>>>>> 1. [deleted thru 12]
>>>>>           
>>>>> 13. Make upper/lower case of simplify/SIMPLIFY consistent on all
>>>>>     apply commands and add a simplify= arg to by.
>>>>>           
>>>> It would have been good not to introduce the inconsistency years ago,
>>>> but it's too late to change now.
>>>>
>>>>         
>>> Really? The consistency issue only concerns mapply, I think.
>>>       
>> mapply and its wrapper Vectorize, and perhaps some functions in
>> contributed packages.
>>
>>     
>>> How 'bout changing the formals of mapply to
>>>
>>> $FUN
>>>
>>>
>>> $...
>>>
>>>
>>> $MoreArgs
>>> NULL
>>>
>>> $SIMPLIFY
>>> simplify
>>>
>>> $USE.NAMES
>>> [1] TRUE
>>>
>>> $simplify
>>> [1] TRUE
>>>
>>> i.e. add simplify = TRUE and change SIMPLIFY's default to 'simplify'
>>>
>>> Then the default behavior is retained, specifying a value for
>>> either SIMPLIFY or simplify gives the desired behavior and SIMPLIFY takes
>>> precedence over simplify if both are given values. Not pretty, perhaps,
>>> but it does the job.
>>>       
>> This allows mapply(..., simplify=TRUE), but is that really "the job"?  I
>> think the point of consistency is to make code easier to read and write,
>> and I'm not sure making this one parameter partially case-insensitive
>> achieves that.  Should the same thing be done to the functions that
>> currently use "simplify", to achieve even more consistency?  Yecch.
>>     
>
> Given that you want to take the step to change/remove an argument, I
> think this is a good strategy; first provide a backward compatible API
> and announce that the original argument is deprecated, and then when
> everyone had a chance to update and test dependent code, you can
> safely remove the argument.
>   
Given that premise, and with the addition that at some point in the 
process using the obsolete parameter would generate a warning, I'd agree. 

But I don't see that the value of the change *in this particular case* 
is worth the effort.

Duncan Murdoch


> My $.02
>
> Henrik
>
>   
>>> I suppose this could get one into trouble if one of the ... args is named
>>> 'simplify', but I do not imagine that is a big deal.
>>>       
>> I think the reasoning behind the choice of SIMPLIFY was probably to
>> avoid a clash with one of the ... args.
>>
>> I'd prefer a more general solution to this problem, like what the Mac
>> GUI does, and giving argument hints as a function call is being typed.
>> (I think ESS may do this too, but I don't use it.)  There are lots of
>> inconsistencies in R functions, and I think making the syntax looser in
>> order to accept a consistent superset is not the right approach:
>> instead, the editor should make it easier for a user to discover what is
>> appropriate in any given context.
>>
>> Duncan Murdoch
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>



[Rd] Wish list
Duncan Murdoch