From: Duncan Murdoch <murdoch_at_stats.uwo.ca>

Date: Tue 02 Jan 2007 - 01:44:40 GMT

>> mapply and its wrapper Vectorize, and perhaps some functions in

*>> contributed packages.
*

>> 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 premise, and with the addition that at some point in the process using the obsolete parameter would generate a warning, I'd agree.

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

*>> https://stat.ethz.ch/mailman/listinfo/r-devel
*

https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue Jan 02 12:51:48 2007

Date: Tue 02 Jan 2007 - 01:44:40 GMT

Henrik Bengtsson wrote:

> On 1/2/07, Duncan Murdoch <murdoch@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

>>

>>

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

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

>>

>> I'd prefer a more general solution to this problem, like what the Mac

>>

>> Duncan Murdoch

>>>> R-devel@r-project.org mailing list

>> ______________________________________________

>> >> >> ______________________________________________R-devel@r-project.org mailing list

https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue Jan 02 12:51:48 2007

Archive maintained by Robert King, hosted by
the discipline of
statistics at the
University of Newcastle,
Australia.

Archive generated by hypermail 2.1.8, at Tue 02 Jan 2007 - 05:31:06 GMT.

*
Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel.
Please read the posting
guide before posting to the list.
*