> On 17 Apr 2017, at 10:04 , Ramnik Bansal <ramnik.ban...@gmail.com> wrote: > > This is my output for is.function > >> is.function("for") > [1] FALSE >> is.function(for) > Error: unexpected ')' in "is.function(for)" >> is.function("next") > [1] FALSE >> is.function(next) > Error: no loop for break/next, jumping to top level > > *I did not get the TRUE value. R version 3.3.3 on Mac. What am I doing > different ?*
You need backticks: > is.function(`for`) [1] TRUE > is.function(`next`) [1] TRUE > `for` .Primitive("for") > `next` .Primitive("next") David either should have typed backticks, or he did type them, only to have a friendly e-mail client autocorrect them into quotes... -pd > > Packages detail >> search() > [1] ".GlobalEnv" "package:pryr" > [3] "tools:RGUI" "package:stats" > [5] "package:graphics" "package:grDevices" > [7] "package:utils" "package:datasets" > [9] "package:methods" "Autoloads" > [11] "package:base" > > thanks > Ramnik > > On Mon, Apr 17, 2017 at 12:06 PM, David Winsemius <dwinsem...@comcast.net> > wrote: > >> Both 'for' and 'next' return TRUE from is.function >> >> is.function('for') >> is.function('next') >> >> Not at an R console at the moment but I did check this earlier today. >> Thinking of it as different is definitely the way to think about it. (ISTR >> Bert and I have had this exchange in the past.) >> >> -- >> Best >> David >> >> Sent from my iPhone >> >>> On Apr 16, 2017, at 9:50 PM, Bert Gunter <bgunter.4...@gmail.com> wrote: >>> >>> David et. al.: >>> >>> "this levels is the level where you realize that the `for` function is >>> different from most other R functions. It is really a >>> side-effect-fucntion. " >>> >>> for(), while(), if(), next, etc. are *not* functions. >>> >>> ?for says: "These are the basic control-flow constructs of the R >> language." >>> >>> They do not "return" values. They control program flow, whence what >>> you call "side effects" are actually expressions that are parsed and >>> evaluated >>> >>> viz. >>> >>>> if(TRUE)10 >>> [1] 10 >>> >>> ## but >>> >>>> if(FALSE) 5 >>> ## nothing is returned, not even NULL >>>> for(i in 1:3) i >>> ## Ditto >>> >>>> z <- NULL >>>> z <- for(i in 1:3)i >>>> z >>> NULL ## still >>> >>> Cheers, >>> Bert >>> >>> >>> >>> >>> Cheers, >>> Bert >>> >>> >>> >>> >>> Bert Gunter >>> >>> "The trouble with having an open mind is that people keep coming along >>> and sticking things into it." >>> -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) >>> >>> >>>> On Sun, Apr 16, 2017 at 8:12 PM, David Winsemius < >> dwinsem...@comcast.net> wrote: >>>> >>>>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <ramnik.ban...@gmail.com> >> wrote: >>>>> >>>>> In the code below >>>>> >>>>> >>>>> *ff <- function(n){ for(i in 1:n) (i+1)}* >>>>> >>>>> *n<-3;ff(n)->op;print(op)* >>>>> >>>>> Why doesnt *print(op) * print 4 and instead prints NULL. >>>>> Isnt the last line of code executed is *i+1 * and therefore that >> should be >>>>> returned instead of NULL >>>>> >>>>> instead if I say >>>>> *ff <- function(n){ (n+1) }* >>>>> >>>>> Then >>>>> *n<-3;ff(n)->op;rm(n);print(op)* >>>>> gives 4 as output. >>>>> >>>>> My question is *Which *is considered as the last line in a functoin >> for the >>>>> purpsoe of default return ? And under what conditions ? >>>> >>>> It's probably a good thing that you are confused. It suggests that you >> are actually "getting" the R-paradigm. Unfortunately for the new user of R, >> there are several levels of understanding to pass through. First, you >> realize that function-results need to be assigned to names in order to >> persist. Then there is the next level where you discover that there are >> exceptions to that rule: this levels is the level where you realize that >> the `for` function is different from most other R functions. It is really >> a side-effect-fucntion. The assignments made within its body actually >> persist in the global environment. AND it returns NULL. It shares this >> anomalous behavior with `while` and `repeat`.n Almost all functions are >> invoked with a possibly empty argument list. The next and break functions >> have implicit paired (empty) parentheses. >>>> >>>> (My personal opinion is that this is not adequately advertised. Perhaps >> it is an attempt to get people to migrate away from "Fortran-coding" >> behavior?) >>>> >>>> -- >>>> David. >>>> >>>> >>>>> >>>>> -Thanks, >>>>> Ramnik >>>>> >>>>> [[alternative HTML version deleted]] >>>>> >>>>> ______________________________________________ >>>>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see >>>>> 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. >>>> >>>> David Winsemius >>>> Alameda, CA, USA >>>> >>>> ______________________________________________ >>>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see >>>> 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. >> >> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > 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. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd....@cbs.dk Priv: pda...@gmail.com ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see 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.