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 ______________________________________________ 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.