sub question

Wacek Kusnierczyk wrote:

Gabor Grothendieck wrote:

This comes from the all.vars function and would indicate
a bug in that base R function.

  

hush!  a user bug, i presume?  but indeed,

all.vars(expression(foo(bar)()))
# character(0)
all.names(expression(foo(bar)()))
# "foo" "bar"

Semantic quibble!

Notice also that (same thing)

all.vars(~ fo(o)(),functions=T)

[1] "~"  "fo" "o"

The quibble is that functions=FALSE (default) can mean

(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?  shouldn't the envisaged rule be
like:

when examining an operator expression,
(a) descend if it is a compound expression
(b) skip if it is a name

then 'foo(bar)()' would decompose to:

[('foo(bar)', '()']
[['foo', 'bar'], []] # by descent
=> ['bar'] # skip 'foo'

where square brackets denote parse tree (first two lines) and the
resulting list of names (last line).  'foo' skipped as being a simple
name in an operator position.

not sure about '~', i guess this is just an operator in the example
above, so it's actually

`~`(, foo(bar) ())

and the rule applies similarly.

what it does is clearly (a), but arguably, (b) is what the
documentation says. This can be resolved in two ways...

Are there "legitimate" reasons to want behaviour (b)? That is,
examples that would reasonably arise in practice.

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. 

vQ