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 > zNULL ## 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 <dwinsemius at comcast.net> wrote:> >> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <ramnik.bansal at 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 at 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 at 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.
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.4567 at 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 <dwinsemius at
comcast.net> wrote:
>>
>>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <ramnik.bansal at
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 at 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 at 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.
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 ?* 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 <dwinsemius at 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.4567 at 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 < > dwinsemius at comcast.net> wrote: > >> > >>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <ramnik.bansal at 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 at 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 at 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]]
OK. I stand corrected. Thanks. -- 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 11:36 PM, David Winsemius <dwinsemius at 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.4567 at 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 <dwinsemius at comcast.net> wrote: >>> >>>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal <ramnik.bansal at 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 at 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 at 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. >