[R] sub question

[Wacek Kusnierczyk]

Peter Dalgaard wrote:
> 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