sub question

Wacek Kusnierczyk wrote:

(a) do not descend recursively into the function part (first element)
of a call
(b) do descend, unless it is a name

if it is a name, how would you descend?  

By calling a recursive function which has it as the argument. It's not
a problem unless you want it to be (first you descend into the first
element on a call, then realize that it is a name). There are
essentially three possibilities (cutting some red tape):

i was half-joking, and none of the below descends on a name.

f <- function(e) if (is.name(e))

  print(e) else if(is.call(e)) invisible(lapply(e,f))

f(~ fo(o)())

`~`
fo
o

f <- function(e) if (is.name(e))

 print(e) else if(is.call(e)) invisible(lapply(e[-1],f))

f(~ fo(o)())

f <- function(e) if (is.name(e)) print(e) else

        if(is.call(e)) invisible( if(is.name(e[[1]]))
             lapply(e[-1],f) else lapply(e,f))

f(~ fo(o)())

o


The first two are essentially the current all.names and all.vars. The
third is the one that you seem to expect. Notice that it gets rather
more complicated than the others.

yes.  'o' is certainly a free variable here, and not one in the operator
position.  which stilld does not mean that it cannot name a function,
but that's a different story, the issue is syntactical here.

the third form above is more complicated in implementation, but not in
use.  the interface is just the same.  sometimes it's better to
complicate the implementation to make the interface better (here:
performing an operation in accordance with the syntax of the language).

 > one legitimate reason is to keep the syntax/semantics clean

(worship the

god of boring pedantry). be this not enough, a practical example
could certainly be found, though
admittedly the above were made up for the discussion. 

But can you be sure that there is no legitimate reason for expecting
the current behaviour?

you surely know the answer.  virtually any feature in r i pointed out as
weird is claimed to be intentional, and thus there is a legitimate
reason (if only the intention itself) for it.  that's why i cannot be
sure this one is not intentional.  that's why it's possible that the
behaviour of gsubfn discussed before is a user bug (user = implementor
of gsubfn).

and of course i can't be sure that there isn't code in some package that
relies on the current behaviour of all.vars.  but if, as you said, this
is not what the documentation says, it should be no obstacle.  gsubfn,
for example, was caught by surprise, and does not seem to demand the
current state of the matters.

is this a design feature?  i guess not, and if it is an implementational
incident, it's not something that should necessarily persist.  perhaps
it's a good idea to do some design thinking first, and then reimplement
the stuff as designed (and documented).  perhaps as yet another all.*
function, or via an additional argument to all.vars.

vQ