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

[Mikael Jagan]

My original posting was lost in the spam filter and apparently not ever seen
by Mailman.  That's fine - at least we have a thread.

I share the sentiment that users who employ '::' in specials (and "experts"
who recommend that) have fundamentally misunderstood specials.  In general,
calls marked as special need not be evaluated.  That they *are* evaluated
in 'mgcv' and 'survival' (and that those packages actually define functions
with names matching the specials) is arguably just an implementation detail
of those packages.

Indeed, by providing a mechanism for detecting "namespaced" specials, we
would be fuelling this misunderstanding.

I'm increasingly partial to leaving R-devel "as is" (after r88066) and trying
to work with the RItools authors to end their usage of

     specials = "<pkg>::<name>"

which now seems a hack to avoid some problem better handled by other means.

Mikael

On 2025-04-15 9:34 am, Therneau, Terry M., Ph.D. wrote:
> 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
>