

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 ?
Thanks,
Ramnik
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


In the first case you have a "for" and it is the statement after the
'for' that is the return value and it is a NULL. For example:
> print(for (i in 1:4) i+1)
NULL
In the second case, the last statement if the expression '(n+1)' which
give you the correct value:
> xx < function(n) n+1
> print(xx(3))
[1] 4
>
Jim Holtman
Data Munger Guru
What is the problem that you are trying to solve?
Tell me what you want to do, not how you want to do it.
On Sun, Apr 16, 2017 at 10:26 PM, Ramnik Bansal < [hidden email]> 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 ?
>
> Thanks,
> Ramnik
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list  To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/rhelp> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html> and provide commented, minimal, selfcontained, reproducible code.
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal < [hidden email]> 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 Rparadigm. Unfortunately for the new user of R, there are several levels of understanding to pass through. First, you realize that functionresults 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 sideeffectfucntion. 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 "Fortrancoding" behavior?)

David.
David Winsemius
Alameda, CA, USA
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


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
sideeffectfucntion. "
for(), while(), if(), next, etc. are *not* functions.
?for says: "These are the basic controlflow 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 < [hidden email]> wrote:
>
>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal < [hidden email]> 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 Rparadigm. Unfortunately for the new user of R, there are several levels of understanding to pass through. First, you realize that functionresults 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 sideeffectfucntion. 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 "Fortrancoding" behavior?)
>
> 
> David.
>
>
>>
>> Thanks,
>> Ramnik
>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> [hidden email] mailing list  To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/rhelp>> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html>> and provide commented, minimal, selfcontained, reproducible code.
>
> David Winsemius
> Alameda, CA, USA
>
> ______________________________________________
> [hidden email] mailing list  To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/rhelp> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html> and provide commented, minimal, selfcontained, reproducible code.
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, 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 < [hidden email]> 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
> sideeffectfucntion. "
>
> for(), while(), if(), next, etc. are *not* functions.
>
> ?for says: "These are the basic controlflow 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 < [hidden email]> wrote:
>>
>>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal < [hidden email]> 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 Rparadigm. Unfortunately for the new user of R, there are several levels of understanding to pass through. First, you realize that functionresults 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 sideeffectfucntion. 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 "Fortrancoding" behavior?)
>>
>> 
>> David.
>>
>>
>>>
>>> Thanks,
>>> Ramnik
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> [hidden email] mailing list  To UNSUBSCRIBE and more, see
>>> https://stat.ethz.ch/mailman/listinfo/rhelp>>> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html>>> and provide commented, minimal, selfcontained, reproducible code.
>>
>> David Winsemius
>> Alameda, CA, USA
>>
>> ______________________________________________
>> [hidden email] mailing list  To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/rhelp>> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html>> and provide commented, minimal, selfcontained, reproducible code.
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, 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 < [hidden email]>
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 < [hidden email]> 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
> > sideeffectfucntion. "
> >
> > for(), while(), if(), next, etc. are *not* functions.
> >
> > ?for says: "These are the basic controlflow 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 <
> [hidden email]> wrote:
> >>
> >>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal < [hidden email]>
> 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 Rparadigm. Unfortunately for the new user of R,
> there are several levels of understanding to pass through. First, you
> realize that functionresults 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 sideeffectfucntion. 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 "Fortrancoding"
> behavior?)
> >>
> >> 
> >> David.
> >>
> >>
> >>>
> >>> Thanks,
> >>> Ramnik
> >>>
> >>> [[alternative HTML version deleted]]
> >>>
> >>> ______________________________________________
> >>> [hidden email] mailing list  To UNSUBSCRIBE and more, see
> >>> https://stat.ethz.ch/mailman/listinfo/rhelp> >>> PLEASE do read the posting guide http://www.Rproject.org/> postingguide.html
> >>> and provide commented, minimal, selfcontained, reproducible code.
> >>
> >> David Winsemius
> >> Alameda, CA, USA
> >>
> >> ______________________________________________
> >> [hidden email] mailing list  To UNSUBSCRIBE and more, see
> >> https://stat.ethz.ch/mailman/listinfo/rhelp> >> PLEASE do read the posting guide http://www.Rproject.org/> postingguide.html
> >> and provide commented, minimal, selfcontained, reproducible code.
>
>
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


> On 17 Apr 2017, at 10:04 , Ramnik Bansal < [hidden email]> 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 email 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 < [hidden email]>
> 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 < [hidden email]> 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
>>> sideeffectfucntion. "
>>>
>>> for(), while(), if(), next, etc. are *not* functions.
>>>
>>> ?for says: "These are the basic controlflow 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 <
>> [hidden email]> wrote:
>>>>
>>>>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal < [hidden email]>
>> 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 Rparadigm. Unfortunately for the new user of R,
>> there are several levels of understanding to pass through. First, you
>> realize that functionresults 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 sideeffectfucntion. 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 "Fortrancoding"
>> behavior?)
>>>>
>>>> 
>>>> David.
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Ramnik
>>>>>
>>>>> [[alternative HTML version deleted]]
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] mailing list  To UNSUBSCRIBE and more, see
>>>>> https://stat.ethz.ch/mailman/listinfo/rhelp>>>>> PLEASE do read the posting guide http://www.Rproject.org/>> postingguide.html
>>>>> and provide commented, minimal, selfcontained, reproducible code.
>>>>
>>>> David Winsemius
>>>> Alameda, CA, USA
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list  To UNSUBSCRIBE and more, see
>>>> https://stat.ethz.ch/mailman/listinfo/rhelp>>>> PLEASE do read the posting guide http://www.Rproject.org/>> postingguide.html
>>>> and provide commented, minimal, selfcontained, reproducible code.
>>
>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list  To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/rhelp> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html> and provide commented, minimal, selfcontained, 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: [hidden email] Priv: [hidden email]
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


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
< [hidden email]> 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 < [hidden email]> 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
>> sideeffectfucntion. "
>>
>> for(), while(), if(), next, etc. are *not* functions.
>>
>> ?for says: "These are the basic controlflow 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 < [hidden email]> wrote:
>>>
>>>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal < [hidden email]> 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 Rparadigm. Unfortunately for the new user of R, there are several levels of understanding to pass through. First, you realize that functionresults 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 sideeffectfucntion. 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 "Fortrancoding" behavior?)
>>>
>>> 
>>> David.
>>>
>>>
>>>>
>>>> Thanks,
>>>> Ramnik
>>>>
>>>> [[alternative HTML version deleted]]
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list  To UNSUBSCRIBE and more, see
>>>> https://stat.ethz.ch/mailman/listinfo/rhelp>>>> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html>>>> and provide commented, minimal, selfcontained, reproducible code.
>>>
>>> David Winsemius
>>> Alameda, CA, USA
>>>
>>> ______________________________________________
>>> [hidden email] mailing list  To UNSUBSCRIBE and more, see
>>> https://stat.ethz.ch/mailman/listinfo/rhelp>>> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html>>> and provide commented, minimal, selfcontained, reproducible code.
>
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


(Apparently I hit "send" too early)
1. I have cc'ed this to the list, as others may well have some good
suggestions re: books.
2. The posting guide is your best resource as to what is appropriate
for the list. I defer to others re: conventions, as I have have been
accused of violating them from time to time.
3. R resources abound. RStudio has some recommendations for web
resource on their site worth checking out:
https://www.rstudio.com/onlinelearning/#RBut there are many others that a search would reveal.
Hadley Wickham has written a couple of books worth checking. I think
that the O'Reilly series might have one or more. It is of course
difficult to judge what "a good book for a newbie" would be in your
mind, but it is hard for me to believe that there aren't at least
several out there.
 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 Mon, Apr 17, 2017 at 1:06 AM, Ramnik Bansal < [hidden email]> wrote:
> Thanks Bert for the reply. It cleared my confusion .
>
> Also am new to the mailing list. Can you please guide me to the mailing list
> norms. For e.g. when I get a reply to my query which imparts me a better
> understanding on the topic, is it a norm to thank the individuals who
> responded, thru a personal mail ? Or it is kind of taken for granted that
> the question has been replied to and an individual thanksreply to reply is
> not even expected as it will increase the number of mails.
>
> Also what seems to be missing is a good book on R which talks about all
> these nuances even for a newbie who wants to master R. Or maybe am unaware
> of one such book.
>
> Best
> Ramnik
>
>
> On Mon, Apr 17, 2017 at 10:20 AM, Bert Gunter < [hidden email]>
> 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
>> sideeffectfucntion. "
>>
>> for(), while(), if(), next, etc. are *not* functions.
>>
>> ?for says: "These are the basic controlflow 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 < [hidden email]>
>> wrote:
>> >
>> >> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal < [hidden email]>
>> >> 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 Rparadigm. Unfortunately for the new user of R,
>> > there are several levels of understanding to pass through. First, you
>> > realize that functionresults 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
>> > sideeffectfucntion. 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 "Fortrancoding"
>> > behavior?)
>> >
>> > 
>> > David.
>> >
>> >
>> >>
>> >> Thanks,
>> >> Ramnik
>> >>
>> >> [[alternative HTML version deleted]]
>> >>
>> >> ______________________________________________
>> >> [hidden email] mailing list  To UNSUBSCRIBE and more, see
>> >> https://stat.ethz.ch/mailman/listinfo/rhelp>> >> PLEASE do read the posting guide
>> >> http://www.Rproject.org/postingguide.html>> >> and provide commented, minimal, selfcontained, reproducible code.
>> >
>> > David Winsemius
>> > Alameda, CA, USA
>> >
>> > ______________________________________________
>> > [hidden email] mailing list  To UNSUBSCRIBE and more, see
>> > https://stat.ethz.ch/mailman/listinfo/rhelp>> > PLEASE do read the posting guide
>> > http://www.Rproject.org/postingguide.html>> > and provide commented, minimal, selfcontained, reproducible code.
>
>
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


Ramnik,
a final mail is actually really important: this is to document in the archives, for the benefit of those who found the thread at a later time, that the responses indeed solved the problem.
Other than that, the single most important advice is to
 provide a minimal working example of the problem;
 state clearly what you expect;
 state explicitly what happened instead.
Apparently you're doing fine in that regard.
B.
> On Apr 17, 2017, at 10:25 AM, Bert Gunter < [hidden email]> wrote:
>
> (Apparently I hit "send" too early)
>
> 1. I have cc'ed this to the list, as others may well have some good
> suggestions re: books.
>
> 2. The posting guide is your best resource as to what is appropriate
> for the list. I defer to others re: conventions, as I have have been
> accused of violating them from time to time.
>
> 3. R resources abound. RStudio has some recommendations for web
> resource on their site worth checking out:
>
> https://www.rstudio.com/onlinelearning/#R>
> But there are many others that a search would reveal.
>
> Hadley Wickham has written a couple of books worth checking. I think
> that the O'Reilly series might have one or more. It is of course
> difficult to judge what "a good book for a newbie" would be in your
> mind, but it is hard for me to believe that there aren't at least
> several out there.
>
>  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 Mon, Apr 17, 2017 at 1:06 AM, Ramnik Bansal < [hidden email]> wrote:
>> Thanks Bert for the reply. It cleared my confusion .
>>
>> Also am new to the mailing list. Can you please guide me to the mailing list
>> norms. For e.g. when I get a reply to my query which imparts me a better
>> understanding on the topic, is it a norm to thank the individuals who
>> responded, thru a personal mail ? Or it is kind of taken for granted that
>> the question has been replied to and an individual thanksreply to reply is
>> not even expected as it will increase the number of mails.
>>
>> Also what seems to be missing is a good book on R which talks about all
>> these nuances even for a newbie who wants to master R. Or maybe am unaware
>> of one such book.
>>
>> Best
>> Ramnik
>>
>>
>> On Mon, Apr 17, 2017 at 10:20 AM, Bert Gunter < [hidden email]>
>> 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
>>> sideeffectfucntion. "
>>>
>>> for(), while(), if(), next, etc. are *not* functions.
>>>
>>> ?for says: "These are the basic controlflow 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 < [hidden email]>
>>> wrote:
>>>>
>>>>> On Apr 16, 2017, at 7:26 PM, Ramnik Bansal < [hidden email]>
>>>>> 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 Rparadigm. Unfortunately for the new user of R,
>>>> there are several levels of understanding to pass through. First, you
>>>> realize that functionresults 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
>>>> sideeffectfucntion. 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 "Fortrancoding"
>>>> behavior?)
>>>>
>>>> 
>>>> David.
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Ramnik
>>>>>
>>>>> [[alternative HTML version deleted]]
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] mailing list  To UNSUBSCRIBE and more, see
>>>>> https://stat.ethz.ch/mailman/listinfo/rhelp>>>>> PLEASE do read the posting guide
>>>>> http://www.Rproject.org/postingguide.html>>>>> and provide commented, minimal, selfcontained, reproducible code.
>>>>
>>>> David Winsemius
>>>> Alameda, CA, USA
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list  To UNSUBSCRIBE and more, see
>>>> https://stat.ethz.ch/mailman/listinfo/rhelp>>>> PLEASE do read the posting guide
>>>> http://www.Rproject.org/postingguide.html>>>> and provide commented, minimal, selfcontained, reproducible code.
>>
>>
>
> ______________________________________________
> [hidden email] mailing list  To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/rhelp> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html> and provide commented, minimal, selfcontained, reproducible code.
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


A long time ago (before the mid1990's?) with S or S+
ff < function(n){ for(i in 1:n) (i+1)
op < ff(3)
would result in 'op' being 4, since a forloop's value
was the value of the last expression executed in the
body of the loop. The presence of a 'next' or 'break'
in the loop body would affect the return value.
This made the primitive garbage collection used the time
not work so well and was one reason that forloops with
lots of iterations ran slowly. Almost no one used
the return value of a forloop so, to avoid memory issues,
for was changed to always return NULL.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Sun, Apr 16, 2017 at 7:26 PM, Ramnik Bansal < [hidden email]> 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 ?
>
> Thanks,
> Ramnik
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list  To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/rhelp> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html> and provide commented, minimal, selfcontained, reproducible code.
______________________________________________
[hidden email] mailing list  To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.

