On Fri, 2011-11-25 at 09:50 -0500, Duncan Murdoch wrote: > I think the general idea in formulas is that it is up to the user to > define the meaning of functions used in them. Normally the user has > attached the package that is working on the formula, so the package > author can provide useful things like s(), but if a user wanted to > redefine s() to their own function, that should be possible. > Formulas > do have environments attached, so both variables and functions should > be > looked up there. >
I don't agree that this is the best way. A function like coxph could easily have in its documentation a list of the "formula specials" that it defines internally. If the user want something of their own they can easily use a different word. In fact, I would strongly recommend that they don't use one of these key names. For things that work across mutiple packages like ns(), what user in his right mind would redefine it? So I re-raise the question. Is there a reasonably simple way to make the survival ridge() function specific to survival formulas? It sets up structures that have no meaning anywhere else, and its global definition stands in the way of other sensible uses. Having it be not exported + obey namespace type sematics would be a plus all around. Philosophical aside: I have discovered to my dismay that formulas do have environments attached, and that variables/functions are looked up there. This made sensible semantics for predict() within a function impossible for some of the survival functions, unless I were to change all the routines to a model=TRUE default. (And a change of that magnitude to survival, with its long list of dependencies, is not fun to contemplate. A very quick survey reveals several dependent packages will break.) So I don't agree nearly so fully with the "should" part of your last sentence. The out of context evaluations allowed by environments are, I find, always tricky and often lead to intricate special cases. Thus, moving back and forth between how it seems that a formula should work, and how it actually does work, sometimes leaves my head spinning. Terry T. Terry Therneau ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
