On Fri, Nov 25, 2011 at 10:37 AM, Terry Therneau <thern...@mayo.edu> wrote: > > 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. >
The dynlm package uses formula functions which are specific to it. Look at its code. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
