[Rd] [EXTERNAL] Re: Request for comment: namespace resolution in terms(<formula>, specials=) [<pkg>::<name>, etc.]

[Therneau, Terry M., Ph.D.]

Peter,
    I had an argument with someone at one of the big companies (google?) several years ago 
over the coding standard you mention, who was claiming that the survival package had a bug 
due to a wrong result using survival::strata() in a formula.   I argued back.

I agree with you that namespacing specials is a bad idea.   But I'm afraid that the 
mistake with specials happens much more often than I'd like.  I find examples in the 
reverse dependencies for survival of 3 different errors, all of which give code that runs 
without an error message, but with the wrong result.    Since I have a strong interest in 
correct results from medical research, I've tried to think about ways to protest the user 
from themselves.   The errors are
    a. using survival::strata(group) in a formula.    This is not recognized as a special.
    b. the package had    zed <- strata(group), then used +zed in multiple formulas.
    c. formula was preprocessed   (I don't remember the detail exactly here, and I expect 
this is rare)

In all three cases the final fit was the same as if they used factor(group).  I expect 
that (a) and (b) are quite prevalent in user code, the second due to all the tutorials 
that like to create a new variable zed <- Surv(time, status) and then use 'zed' in the 
formulas, people will do the same with strata.    (I don't like this approach in general; 
you've saved a tiny bit of typing to create fits that are less clearly documented.)

When reading one of my colleagues grants, before submission, I often try to actively try 
to put on a "pretend I don't know this topic deeply" persona, so as to note passages where 
other readers might go wrong, e.g., completely misunderstand a sentence.   I'm trying to 
think about specials with a bit of that bias as well, when might a naive but well meaning 
user go wrong?   Is there something fairly simple I could do in the package coding to 
avert it?    I'm thinking that the only solution to (b) above will be to have strata 
return a classed object and key on the class rather depend on specials.    It will be a 
lot of busywork to implement though.

I have no particular votes for against the proposed change: I have a general opinion that 
those who insist on using non-syntactic names have fallen into a pit that they dug 
themselves, and little sympathy for their plight.

Terry T

On 4/15/25 03:17, peter dalgaard wrote:
> I don't seem to have the original post (not in spamfilter either). But
> generically, I think namespacing specials in formulas is just a Bad
> Idea. They are syntactic constructs, specifically_not_
>   function calls, so people are stumbling over formally protecting them
> from a non-existing scoping issue, then having to undo that for the
> actual use.
>
> It all came about by someone (I have forgotten the details) having a
> corporate coding standard mandating namespaces on all function calls and
>   falling over things like strata() in the survival package. Then package
>   author(s) chose to comply rather than explain...
>
> -pd

	[[alternative HTML version deleted]]