Without having dug into the details, it could be that one could update the parser by making a 'return' a keyword and require it to be followed by a parenthesis that optionally contains an expression followed by end of statement (newline or semicolon). Such a "promotion" of the 'return' statement seems backward compatible and would end up throwing syntax errors on: function() return function() return 2*x function() return (2*x) + 1 while still accepting: function() return() function() return(2*x) function() return((2*x) + 1) Just my two Friday cents /Henrik On Fri, Nov 20, 2020 at 3:37 PM D?nes T?th <toth.denes at kogentum.hu> wrote:> > Yes, the behaviour of return() is absolutely consistent. I am wondering > though how many experienced R developers would predict the correct > return value just by looking at those code snippets. > > On 11/21/20 12:33 AM, Gabriel Becker wrote: > > And the related: > > > > > f = function() stop(return("lol")) > > > > > f() > > > > [1] "lol" > > > > > > I have a feeling all of this is just return() performing correctly > > though. If there are already R CMD CHECK checks for this kind of thing > > (I wasnt sure but I'm hearing from others there may be/are) that may be > > (and/or may need to be) sufficient. > > > > ~G > > > > On Fri, Nov 20, 2020 at 3:27 PM D?nes T?th <toth.denes at kogentum.hu > > <mailto:toth.denes at kogentum.hu>> wrote: > > > > Or even more illustratively: > > > > uneval_after_return <- function(x) { > > return(x) * stop("Not evaluated") > > } > > uneval_after_return(1) > > # [1] 1 > > > > On 11/20/20 10:12 PM, Mateo Obreg?n wrote: > > > Dear r-developers- > > > > > > After many years of using and coding in R and other languages, I > > came across > > > something that I think should be flagged by the parser: > > > > > > bug <- function (x) { > > > return (x + 1) * 1000 > > > } > > >> bug(1) > > > [1] 2 > > > > > > The return() call is not like any other function call that > > returns a value to > > > the point where it was called from. I think this should > > straightforwardly be > > > handled in the parser by flagging it as a syntactic error. > > > > > > Thoughts? > > > > > > Mateo. > > > -- > > > Mateo Obreg?n. > > > > > > ______________________________________________ > > > R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > ______________________________________________ > > R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
I may be unusual but I don't find these examples surprising at all/ I don't think I would make these mistakes (maybe it's easier to make that mistake if you're used to a language where 'return' is a keyword rather than a function? My two cents would be that it would make more sense to (1) write code to detect these constructions in existing R code (I'm not good at this, but presumably "return() as anything other than the head of an element of the body of a function" would work?) (2) apply it to some corpus of R code to see whether it actually happens much; (3) if so, add the test you wrote in step 1 to the QA tools in the utils package/CRAN checks. On Fri, Nov 20, 2020 at 6:58 PM Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote:> > Without having dug into the details, it could be that one could update > the parser by making a 'return' a keyword and require it to be > followed by a parenthesis that optionally contains an expression > followed by end of statement (newline or semicolon). Such a > "promotion" of the 'return' statement seems backward compatible and > would end up throwing syntax errors on: > > function() return > function() return 2*x > function() return (2*x) + 1 > > while still accepting: > > function() return() > function() return(2*x) > function() return((2*x) + 1) > > Just my two Friday cents > > /Henrik > > On Fri, Nov 20, 2020 at 3:37 PM D?nes T?th <toth.denes at kogentum.hu> wrote: > > > > Yes, the behaviour of return() is absolutely consistent. I am wondering > > though how many experienced R developers would predict the correct > > return value just by looking at those code snippets. > > > > On 11/21/20 12:33 AM, Gabriel Becker wrote: > > > And the related: > > > > > > > f = function() stop(return("lol")) > > > > > > > f() > > > > > > [1] "lol" > > > > > > > > > I have a feeling all of this is just return() performing correctly > > > though. If there are already R CMD CHECK checks for this kind of thing > > > (I wasnt sure but I'm hearing from others there may be/are) that may be > > > (and/or may need to be) sufficient. > > > > > > ~G > > > > > > On Fri, Nov 20, 2020 at 3:27 PM D?nes T?th <toth.denes at kogentum.hu > > > <mailto:toth.denes at kogentum.hu>> wrote: > > > > > > Or even more illustratively: > > > > > > uneval_after_return <- function(x) { > > > return(x) * stop("Not evaluated") > > > } > > > uneval_after_return(1) > > > # [1] 1 > > > > > > On 11/20/20 10:12 PM, Mateo Obreg?n wrote: > > > > Dear r-developers- > > > > > > > > After many years of using and coding in R and other languages, I > > > came across > > > > something that I think should be flagged by the parser: > > > > > > > > bug <- function (x) { > > > > return (x + 1) * 1000 > > > > } > > > >> bug(1) > > > > [1] 2 > > > > > > > > The return() call is not like any other function call that > > > returns a value to > > > > the point where it was called from. I think this should > > > straightforwardly be > > > > handled in the parser by flagging it as a syntactic error. > > > > > > > > Thoughts? > > > > > > > > Mateo. > > > > -- > > > > Mateo Obreg?n. > > > > > > > > ______________________________________________ > > > > R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > ______________________________________________ > > > R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
On 20/11/2020 7:01 p.m., Ben Bolker wrote:> I may be unusual but I don't find these examples surprising at all/ > I don't think I would make these mistakes (maybe it's easier to make > that mistake if you're used to a language where 'return' is a keyword > rather than a function? > > My two cents would be that it would make more sense to (1) write > code to detect these constructions in existing R code (I'm not good at > this, but presumably "return() as anything other than the head of an > element of the body of a function" would work?)No, it's commonly nested within an if() expression, and could appear anywhere else. (2) apply it to some> corpus of R code to see whether it actually happens much;I did that, in the bug report #17180 I cited. In 2016 it appeared to be misused in about 100 packages. (3) if so,> add the test you wrote in step 1 to the QA tools in the utils > package/CRAN checks.That was done this year. Duncan Murdoch> > On Fri, Nov 20, 2020 at 6:58 PM Henrik Bengtsson > <henrik.bengtsson at gmail.com> wrote: >> >> Without having dug into the details, it could be that one could update >> the parser by making a 'return' a keyword and require it to be >> followed by a parenthesis that optionally contains an expression >> followed by end of statement (newline or semicolon). Such a >> "promotion" of the 'return' statement seems backward compatible and >> would end up throwing syntax errors on: >> >> function() return >> function() return 2*x >> function() return (2*x) + 1 >> >> while still accepting: >> >> function() return() >> function() return(2*x) >> function() return((2*x) + 1) >> >> Just my two Friday cents >> >> /Henrik >> >> On Fri, Nov 20, 2020 at 3:37 PM D?nes T?th <toth.denes at kogentum.hu> wrote: >>> >>> Yes, the behaviour of return() is absolutely consistent. I am wondering >>> though how many experienced R developers would predict the correct >>> return value just by looking at those code snippets. >>> >>> On 11/21/20 12:33 AM, Gabriel Becker wrote: >>>> And the related: >>>> >>>> > f = function() stop(return("lol")) >>>> >>>> > f() >>>> >>>> [1] "lol" >>>> >>>> >>>> I have a feeling all of this is just return() performing correctly >>>> though. If there are already R CMD CHECK checks for this kind of thing >>>> (I wasnt sure but I'm hearing from others there may be/are) that may be >>>> (and/or may need to be) sufficient. >>>> >>>> ~G >>>> >>>> On Fri, Nov 20, 2020 at 3:27 PM D?nes T?th <toth.denes at kogentum.hu >>>> <mailto:toth.denes at kogentum.hu>> wrote: >>>> >>>> Or even more illustratively: >>>> >>>> uneval_after_return <- function(x) { >>>> return(x) * stop("Not evaluated") >>>> } >>>> uneval_after_return(1) >>>> # [1] 1 >>>> >>>> On 11/20/20 10:12 PM, Mateo Obreg?n wrote: >>>> > Dear r-developers- >>>> > >>>> > After many years of using and coding in R and other languages, I >>>> came across >>>> > something that I think should be flagged by the parser: >>>> > >>>> > bug <- function (x) { >>>> > return (x + 1) * 1000 >>>> > } >>>> >> bug(1) >>>> > [1] 2 >>>> > >>>> > The return() call is not like any other function call that >>>> returns a value to >>>> > the point where it was called from. I think this should >>>> straightforwardly be >>>> > handled in the parser by flagging it as a syntactic error. >>>> > >>>> > Thoughts? >>>> > >>>> > Mateo. >>>> > -- >>>> > Mateo Obreg?n. >>>> > >>>> > ______________________________________________ >>>> > R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list >>>> > https://stat.ethz.ch/mailman/listinfo/r-devel >>>> > >>>> >>>> ______________________________________________ >>>> R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >