William Dunlap wrote: > Would it make anyone any happier if the manual said > that the replacement functions should not be called > in the form > xNew <- `func<-` (xOld, value) > and should only be used as > func(xToBeChanged) <- value >
surely better than guesswork. > ? > > The explanation > names(x) <- c("a","b") > is equivalent to > '*tmp*' <- x > x <- "names<-"('*tmp*', value=c("a","b")) > could also be extended a bit, adding a line like > rm(`*tmp*`) > Those 3 lines should be considered an atomic operation: > the value that `*tmp*` or `x` may have or what is > in the symbol table at various points in that sequence > is not defined. (Letting details be explicitly undefined > is important: it gives developers room to improve the > efficiency of the interpreter and tells users where not to go.) > there is a difference between letting things be undefined and explicitly stating that things are unspecified. the c99 standard [1], for example, is explicit about the non-determinism of expressions that involve side effects, as it is about that some expressions may actually not be evaluated if the optimizer decides so. berwin has already suggested that one reads from what docs do *not* say; it's a very bad idea. it's best that the documentation *does* say that, for example, a particular function should be used only in the infix form because the semantics of the prefix form are not guaranteed and may change in future versions. if the current state is that 'names<-' will modify the object it is given as an argument in some situations, but not in others, and this is visible to the user, the best thing to do is to give an explicit warning -- perhaps with an annotation that things may change, if they may. best, vQ [1] http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel