Re: [Rd] An update method for lists?

From: Deepayan Sarkar <deepayan.sarkar_at_gmail.com>
Date: Tue 19 Sep 2006 - 20:48:52 GMT

On 9/19/06, Gabor Grothendieck <ggrothendieck@gmail.com> wrote:
> Perhaps it should have another name, be made generic and extended
> to functions in which case it would work on the formal arguments. e.g.
>
> read.table.comma <- modify(read.table, list(sep = ","))
>
> would return a function that is the same as read.table but
> has "," as the default for sep.
>
> Python has something like this called partial:
> http://docs.python.org/dev/whatsnew/pep-309.html

I have had similar thoughts, and even requested a variant a while back, with a possible implementation:

https://stat.ethz.ch/pipermail/r-devel/2006-March/036696.html

Again, the main question is whether it makes sense to introduce this in `one of the base packages'.

-Deepayan

> On 9/18/06, Deepayan Sarkar <deepayan.sarkar@gmail.com> wrote:
> > On 9/15/06, Deepayan Sarkar <deepayan.sarkar@gmail.com> wrote:
> > > On 9/15/06, Martin Maechler <maechler@stat.math.ethz.ch> wrote:
> > > > >>>>> "DeepS" == Deepayan Sarkar <deepayan.sarkar@gmail.com>
> > > > >>>>> on Fri, 15 Sep 2006 12:22:15 -0700 writes:
> > > >
> > > > DeepS> Hi, since lattice uses nested lists in various
> > > > DeepS> situations, it has had an unexported function called
> > > > DeepS> updateList for a while, which looks like
> > > >
> > > > >> > lattice:::updateList
> > > > >> function (x, val)
> > > > >> {
> > > > >> if (is.null(x))
> > > > >> x <- list()
> > > > >> if (!is.list(x))
> > > > >> stop("x must be NULL or a list")
> > > > >> if (!is.list(val))
> > > > >> stop("val must be a list")
> > > > >> xnames <- names(x)
> > > > >> for (v in names(val)) {
> > > > >> existing <- v %in% xnames
> > > > >> if (existing && is.list(x[[v]]) && is.list(val[[v]]))
> > > > >> x[[v]] <- updateList(x[[v]], val[[v]])
> > > > >> else x[[v]] <- val[[v]]
> > > > >> }
> > > > >> x
> > > > >> }
> > > >
> > > > [I'm not sure I'd allow NULL for 'x'; typing list() instead of
> > > > NULL is not much more, but when the function name even includes 'list'
> > > > I'd really require a list for 'x']
> > >
> > > Makes sense.
> > >
> > > > You could hence collapse the first 6 lines to the single
> > > >
> > > > stopifnot(is.list(x), is.list(val))
> > >
> > > I'll check if lattice needs some fixes with this.
> >
> > Actually, I do need to allow NULL, because update.trellis does things like
> >
> > update.trellis <- function(object, ..., par.strip.text, ...)
> > {
> > ...
> > object$par.strip.text <- updateList(object$par.strip.text, par.strip.text)
> > ...
> > }
> >
> > where object$par.strip.text may be initially NULL. But I'll do that
> > inside a lattice wrapper.
> >
> > > > DeepS> Basically, it recursively replaces elements that have
> > > > DeepS> been specified in val, leaving the other components
> > > > DeepS> alone. I'm not aware of any other actual situation
> > > > DeepS> where this is useful, but it certainly can be, so I
> > > > DeepS> want to export this functionaliy. At least one other
> > > > DeepS> person (Gabor) has also asked for that.
> > > >
> > > > I've had a similar need only recently:
> > > > If a list is used to store "defaults" and you want a safe way to
> > > > change only a few of the values...
> > > > I presume you use this for manipulating the settings of lattice
> > > > parts ?
> > >
> > > Yes, it's primarily used inside trellis.par.set, but many other places as well.
> > >
> > > > DeepS> Now, as the name suggests, I think it might be
> > > > DeepS> reasonable to export this as an update method for
> > > > DeepS> "list" objects. Depending on what others (in
> > > > DeepS> particular r-core) think, one of these things might
> > > > DeepS> happen:
> > > >
> > > > DeepS> (1) I export it as updateList (or some other name) in lattice
> > > > DeepS> (2) I export it as an S3 method update.list in lattice
> > > > DeepS> (3) It gets added as an S3 method update.list in one of the base packages
> > > > or
> > > > (4) it gets added as utility function updateList() to
> > > > 'utils' {= one of the base packages}
> > >
> > > Yes, that a good option too (certainly better than (1))
> > >
> > > > which I'd favor momentarily.
> > > > - update() is typically for updating *models*
> > > > - it's not clear that this is *the* method for update()ing a list
> > >
> > > I agree. Part of the reason I brought this up is because it is not
> > > clear to me what justifies a new method for an existing generic. An
> > > argument for is that one doesn't introduce yet another function, which
> > > (I thought) might be enough if the other choice is to not have any
> > > method at all.
> > >
> > > > I'm also a bit wondering if it wouldn't make sense to change the name to
> > > > something like assignInList().
> > >
> > > I'm open to suggestions for the name. I didn't think too much about it
> > > since it was unexported anyway.
> > >
> > > > DeepS> The default option is (1), and I guess Sept 19 is the deadline for any
> > > > DeepS> of these to be included in R 2.4.0.
> > > >
> > > > Yes, that's true for (3) & (4) are higher if you provide a patch
> > > > to R-devel (not R-alpha) which includes a man page ... [but
> > > > don't hurry, I'd like to see other comments]
> >
> > I have checked in
> >
> > https://svn.r-project.org/R-packages/trunk/lattice/R/modifyList.R
> > https://svn.r-project.org/R-packages/trunk/lattice/man/modifyList.Rd
> >
> > which I'm happy to offer for inclusion in utils or wherever might seem
> > appropriate. I'll upload a version of lattice which includes these
> > late tomorrow if I don't see any more comments by then.
> >
> > I've changed the name because I wasn't sure if assignInList might be
> > confusing, as the semantics are different from those of assign (assign
> > is like 'fix', while this is more like 'edit'). However, any name is
> > fine with me.
> >
> > Deepayan



R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Wed Sep 20 06:51:41 2006

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 Thu 21 Sep 2006 - 09:30:12 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.