[R] sub question

[Wacek Kusnierczyk]

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