From hb at stat.berkeley.edu  Tue Jan  2 02:35:18 2007
From: hb at stat.berkeley.edu (Henrik Bengtsson)
Date: Tue, 2 Jan 2007 12:35:18 +1100
Subject: [Rd] Wish list
In-Reply-To: <4599A81D.6050202@stats.uwo.ca>
References: <971536df0612312228i4a4bb0b2h6c52c081213c296@mail.gmail.com>
	<45993282.7030409@stats.uwo.ca>
	<Pine.LNX.4.64.0701010946250.6276@tajo.ucsd.edu>
	<4599A81D.6050202@stats.uwo.ca>
Message-ID: <59d7961d0701011735l187466c2v60a32576f35ef2e3@mail.gmail.com>

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.

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