An update method for lists?

On 9/19/06, Gabor Grothendieck <ggrothendieck at 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 at gmail.com> wrote:

On 9/15/06, Deepayan Sarkar <deepayan.sarkar at gmail.com> wrote:

On 9/15/06, Martin Maechler <maechler at stat.math.ethz.ch> wrote:

"DeepS" == Deepayan Sarkar <deepayan.sarkar at 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