Peter Dalgaard wrote: > 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 ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.