Re: [Rd] return (x+1) * 1000
OK, you're way ahead of me. If this is in the QA tools, I guess I
don't really see the need to change the parser and/or the language to
flag it immediately?
On Fri, Nov 20, 2020 at 7:43 PM Duncan Murdoch wrote:
>
> 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
> > 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 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 > 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@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> >>>
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
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
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 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 mailto:toth.de...@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
On Fri, Nov 20, 2020 at 02:48:11PM -0800, Bill Dunlap wrote:
> Perhaps the parser should warn if you use return() at all. It is rarely
> needed and is akin to the evil 'GOTO' statement in that it makes the flow
> of control less obvious to the reader.
My experience is contrary to this, using return explicitly makes
code more readable for a substantial proportion of coders. This is
based on debugging return-unaware code, and helping others debug,
over many years, and finding that a considerable proportion of people
aren't very aware of the implicit return of the last evaluated
expression. Examples that I've known to cause people to despair
include code "mysteriously" going wrong after appending an "innocent"
statement like
print(x);
to a function (so the function now returns x, rather than whatever
it was returning before), or functions returning something unintended
in some rather rare combination of conditions.
>From a language design perspective it seems to me that perhaps a cause
of the problem is that return is not a keyword like "function", but a
function itself -- and, of necessity, a rather peculiar one.
Personally, I'd prefer upgrading return to a keyword, as I can't think
of any way of preventing the weirdnesses discussed in this thread while
preserving the function implementation of "return". This would also be
a step towards getting the parser to warn about uses of return that
are considered undesirable -- with the current function implementation,
the parser can't really tell whether any call will effectively be to
return, it could be anything looking as innocent as "f":
demo <- function(x, f) { message("hello"); print(f(x)); message("bye"); }
demo(3, mean);
demo(3, return);
Best regards, Jan
> -Bill
>
> On Fri, Nov 20, 2020 at 2:37 PM Mateo Obregón
> wrote:
>
> > I'm not thinking of complicated cases.
> >
> > This happened to me in a function that returns 10 minute slots
> >
> > slot <- function (seconds) {
> > return (seconds %/% 600) * 600
> > }
> >
> > Obviously I found the issue while debugging and corrected my code with
> > surrounding parenthesis, but I was surprised that the R parser did not
> > catch
> > this syntactic error.
> >
> > This is especially poignant when we have to switch between languages like
> > python where the original line would produce the desired result.
> >
> > Mateo.
> > --
> > Mateo Obregón.
> >
> > On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:
> > > Hi all,
> > >
> > > I can confirm this occurs for me as well.
> > >
> > > The one thing that comes to mind is that there are certain larger
> > > expressions that contain calls to return which we absolutely don't want
> > to
> > > be an error, e.g
> > >
> > > if(somestuff)
> > > return(TRUE)
> > >
> > >
> > > That said, the actual expression Mateo pointed out certainly does look
> > like
> > > an error (it definitely isn't going to do what the developer intended).
> > >
> > > I haven't looked at the parser much, to be honest. I assume there is
> > > perhaps enough differentiation of if/else that return() could be allowed
> > > within that but not inside a larger expression without it?
> > >
> > > There would be things that are legal (though horrifying) now that would
> > > stop working though, such as:
> > >
> > > f = function(a) {
> > >
> > > ret = switch(a,
> > >
> > > "1"= return("haha got 1!"),
> > >
> > > "2" = "regular ole 2")
> > >
> > > ret
> > >
> > > }
> > >
> > >
> > > Whether it would be a problem or not that such insanity wouldn't work is
> > > less clear. Are there valid non-if embedded return() cases that are
> > > important to allow? If so (and if they're not differentiated by the
> > parser,
> > > which I somewhat doubt switch is, for example, though I'm not certain),
> > I'm
> > > skeptical we'd be able to do as he suggests.
> > >
> > > It does seem worth considering though. If it can't be a hard parse error
> > > but we agree many/most cases are problematic, perhaps adding detecting
> > this
> > > to the static checks that R CMD CHECK performs is another way forward.
> > >
> > > Best,
> > > ~G
> > >
> > > On Fri, Nov 20, 2020 at 1:34 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.
> > > >
> > > > __
Re: [Rd] return (x+1) * 1000
On 20/11/2020 5:58 p.m., Mateo Obregón wrote:
I don't see how anything operating on the "result" of a return() call could be
legal. The special semantics of the return() call is that it does **not**
return control to the place it was called from, but rather to the location
where its surrounding function(){} was called from.
The problem is that in R, return() is a function. It's a function that
does weird things, but it's not a reserved word like it is in some other
languages. If you don't like the standard definition, you can change it:
return <- function() 3
f <- function() return()
f()
which will return 3.
Duncan Murdoch
Mateo.
--
Mateo Obregón.
On Friday, 20 November 2020 22:52:58 GMT Duncan Murdoch wrote:
On 20/11/2020 5:36 p.m., Mateo Obregón wrote:
I'm not thinking of complicated cases.
This happened to me in a function that returns 10 minute slots
slot <- function (seconds) {
return (seconds %/% 600) * 600
}
Obviously I found the issue while debugging and corrected my code with
surrounding parenthesis, but I was surprised that the R parser did not
catch this syntactic error.
This is especially poignant when we have to switch between languages like
python where the original line would produce the desired result.
That's legal code, so the parser can't catch it, it needs to be caught
by some lint-like thing that looks for bad usage. The package check
code has lots of that kind of check (including this one, though not yet
in released R). So if you put this in a package and run the --as-cran
checks in R-devel, you'll be notified about it.
The fact that Python is different is something that's always going to
cause problems for people who are more familiar with Python. I don't
know Python well enough to list all the gotchas, but I'm sure there are
lots of them.
Duncan Murdoch
Mateo.
--
Mateo Obregón.
On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:
Hi all,
I can confirm this occurs for me as well.
The one thing that comes to mind is that there are certain larger
expressions that contain calls to return which we absolutely don't want
to
be an error, e.g
if(somestuff)
return(TRUE)
That said, the actual expression Mateo pointed out certainly does look
like
an error (it definitely isn't going to do what the developer intended).
I haven't looked at the parser much, to be honest. I assume there is
perhaps enough differentiation of if/else that return() could be allowed
within that but not inside a larger expression without it?
There would be things that are legal (though horrifying) now that would
stop working though, such as:
f = function(a) {
ret = switch(a,
"1"= return("haha got 1!"),
"2" = "regular ole 2")
ret
}
Whether it would be a problem or not that such insanity wouldn't work is
less clear. Are there valid non-if embedded return() cases that are
important to allow? If so (and if they're not differentiated by the
parser,
which I somewhat doubt switch is, for example, though I'm not certain),
I'm
skeptical we'd be able to do as he suggests.
It does seem worth considering though. If it can't be a hard parse error
but we agree many/most cases are problematic, perhaps adding detecting
this
to the static checks that R CMD CHECK performs is another way forward.
Best,
~G
On Fri, Nov 20, 2020 at 1:34 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
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
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 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 > > > 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@r-project.org mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > > >
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
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 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 > > 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@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
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 > 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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
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 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@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
I don't see how anything operating on the "result" of a return() call could be
legal. The special semantics of the return() call is that it does **not**
return control to the place it was called from, but rather to the location
where its surrounding function(){} was called from.
Mateo.
--
Mateo Obregón.
On Friday, 20 November 2020 22:52:58 GMT Duncan Murdoch wrote:
> On 20/11/2020 5:36 p.m., Mateo Obregón wrote:
> > I'm not thinking of complicated cases.
> >
> > This happened to me in a function that returns 10 minute slots
> >
> > slot <- function (seconds) {
> >
> > return (seconds %/% 600) * 600
> >
> > }
> >
> > Obviously I found the issue while debugging and corrected my code with
> > surrounding parenthesis, but I was surprised that the R parser did not
> > catch this syntactic error.
> >
> > This is especially poignant when we have to switch between languages like
> > python where the original line would produce the desired result.
>
> That's legal code, so the parser can't catch it, it needs to be caught
> by some lint-like thing that looks for bad usage. The package check
> code has lots of that kind of check (including this one, though not yet
> in released R). So if you put this in a package and run the --as-cran
> checks in R-devel, you'll be notified about it.
>
> The fact that Python is different is something that's always going to
> cause problems for people who are more familiar with Python. I don't
> know Python well enough to list all the gotchas, but I'm sure there are
> lots of them.
>
> Duncan Murdoch
>
> > Mateo.
> > --
> > Mateo Obregón.
> >
> > On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:
> >> Hi all,
> >>
> >> I can confirm this occurs for me as well.
> >>
> >> The one thing that comes to mind is that there are certain larger
> >> expressions that contain calls to return which we absolutely don't want
> >> to
> >> be an error, e.g
> >>
> >> if(somestuff)
> >>
> >> return(TRUE)
> >>
> >> That said, the actual expression Mateo pointed out certainly does look
> >> like
> >> an error (it definitely isn't going to do what the developer intended).
> >>
> >> I haven't looked at the parser much, to be honest. I assume there is
> >> perhaps enough differentiation of if/else that return() could be allowed
> >> within that but not inside a larger expression without it?
> >>
> >> There would be things that are legal (though horrifying) now that would
> >> stop working though, such as:
> >>
> >> f = function(a) {
> >>
> >> ret = switch(a,
> >>
> >> "1"= return("haha got 1!"),
> >>
> >> "2" = "regular ole 2")
> >>
> >> ret
> >>
> >> }
> >>
> >>
> >> Whether it would be a problem or not that such insanity wouldn't work is
> >> less clear. Are there valid non-if embedded return() cases that are
> >> important to allow? If so (and if they're not differentiated by the
> >> parser,
> >> which I somewhat doubt switch is, for example, though I'm not certain),
> >> I'm
> >> skeptical we'd be able to do as he suggests.
> >>
> >> It does seem worth considering though. If it can't be a hard parse error
> >> but we agree many/most cases are problematic, perhaps adding detecting
> >> this
> >> to the static checks that R CMD CHECK performs is another way forward.
> >>
> >> Best,
> >> ~G
> >>
> >> On Fri, Nov 20, 2020 at 1:34 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@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
Perhaps the parser should warn if you use return() at all. It is rarely
needed and is akin to the evil 'GOTO' statement in that it makes the flow
of control less obvious to the reader.
-Bill
On Fri, Nov 20, 2020 at 2:37 PM Mateo Obregón
wrote:
> I'm not thinking of complicated cases.
>
> This happened to me in a function that returns 10 minute slots
>
> slot <- function (seconds) {
> return (seconds %/% 600) * 600
> }
>
> Obviously I found the issue while debugging and corrected my code with
> surrounding parenthesis, but I was surprised that the R parser did not
> catch
> this syntactic error.
>
> This is especially poignant when we have to switch between languages like
> python where the original line would produce the desired result.
>
> Mateo.
> --
> Mateo Obregón.
>
> On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:
> > Hi all,
> >
> > I can confirm this occurs for me as well.
> >
> > The one thing that comes to mind is that there are certain larger
> > expressions that contain calls to return which we absolutely don't want
> to
> > be an error, e.g
> >
> > if(somestuff)
> > return(TRUE)
> >
> >
> > That said, the actual expression Mateo pointed out certainly does look
> like
> > an error (it definitely isn't going to do what the developer intended).
> >
> > I haven't looked at the parser much, to be honest. I assume there is
> > perhaps enough differentiation of if/else that return() could be allowed
> > within that but not inside a larger expression without it?
> >
> > There would be things that are legal (though horrifying) now that would
> > stop working though, such as:
> >
> > f = function(a) {
> >
> > ret = switch(a,
> >
> > "1"= return("haha got 1!"),
> >
> > "2" = "regular ole 2")
> >
> > ret
> >
> > }
> >
> >
> > Whether it would be a problem or not that such insanity wouldn't work is
> > less clear. Are there valid non-if embedded return() cases that are
> > important to allow? If so (and if they're not differentiated by the
> parser,
> > which I somewhat doubt switch is, for example, though I'm not certain),
> I'm
> > skeptical we'd be able to do as he suggests.
> >
> > It does seem worth considering though. If it can't be a hard parse error
> > but we agree many/most cases are problematic, perhaps adding detecting
> this
> > to the static checks that R CMD CHECK performs is another way forward.
> >
> > Best,
> > ~G
> >
> > On Fri, Nov 20, 2020 at 1:34 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@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
On 20/11/2020 5:36 p.m., Mateo Obregón wrote:
I'm not thinking of complicated cases.
This happened to me in a function that returns 10 minute slots
slot <- function (seconds) {
return (seconds %/% 600) * 600
}
Obviously I found the issue while debugging and corrected my code with
surrounding parenthesis, but I was surprised that the R parser did not catch
this syntactic error.
This is especially poignant when we have to switch between languages like
python where the original line would produce the desired result.
That's legal code, so the parser can't catch it, it needs to be caught
by some lint-like thing that looks for bad usage. The package check
code has lots of that kind of check (including this one, though not yet
in released R). So if you put this in a package and run the --as-cran
checks in R-devel, you'll be notified about it.
The fact that Python is different is something that's always going to
cause problems for people who are more familiar with Python. I don't
know Python well enough to list all the gotchas, but I'm sure there are
lots of them.
Duncan Murdoch
Mateo.
--
Mateo Obregón.
On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:
Hi all,
I can confirm this occurs for me as well.
The one thing that comes to mind is that there are certain larger
expressions that contain calls to return which we absolutely don't want to
be an error, e.g
if(somestuff)
return(TRUE)
That said, the actual expression Mateo pointed out certainly does look like
an error (it definitely isn't going to do what the developer intended).
I haven't looked at the parser much, to be honest. I assume there is
perhaps enough differentiation of if/else that return() could be allowed
within that but not inside a larger expression without it?
There would be things that are legal (though horrifying) now that would
stop working though, such as:
f = function(a) {
ret = switch(a,
"1"= return("haha got 1!"),
"2" = "regular ole 2")
ret
}
Whether it would be a problem or not that such insanity wouldn't work is
less clear. Are there valid non-if embedded return() cases that are
important to allow? If so (and if they're not differentiated by the parser,
which I somewhat doubt switch is, for example, though I'm not certain), I'm
skeptical we'd be able to do as he suggests.
It does seem worth considering though. If it can't be a hard parse error
but we agree many/most cases are problematic, perhaps adding detecting this
to the static checks that R CMD CHECK performs is another way forward.
Best,
~G
On Fri, Nov 20, 2020 at 1:34 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
On 20/11/2020 5:16 p.m., Henrik Bengtsson wrote:
FWIW, 'R CMD check --as-cran' in R-devel checks for "bogus return"
statements but I think that's only for the case when one forgets the
parentheses, e.g. 'return' instead of 'return()'.
I don't think it catches this case but I'm also not sure. Though, I can
imagine it might be possible to enhance the current check to include also
this case.
It could be that setting _R_CHECK_BOGUS_RETURN_=true will enable this check
also in earlier versions in R; not sure when it was introduced.
It's quite recent (August of this year): see
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17180.
Duncan Murdoch
/Henrik
On Fri, Nov 20, 2020, 13:58 Gabriel Becker wrote:
Hi all,
I can confirm this occurs for me as well.
The one thing that comes to mind is that there are certain larger
expressions that contain calls to return which we absolutely don't want to
be an error, e.g
if(somestuff)
return(TRUE)
That said, the actual expression Mateo pointed out certainly does look like
an error (it definitely isn't going to do what the developer intended).
I haven't looked at the parser much, to be honest. I assume there is
perhaps enough differentiation of if/else that return() could be allowed
within that but not inside a larger expression without it?
There would be things that are legal (though horrifying) now that would
stop working though, such as:
f = function(a) {
ret = switch(a,
"1"= return("haha got 1!"),
"2" = "regular ole 2")
ret
}
Whether it would be a problem or not that such insanity wouldn't work is
less clear. Are there valid non-if embedded return() cases that are
important to allow? If so (and if they're not differentiated by the parser,
which I somewhat doubt switch is, for example, though I'm not certain), I'm
skeptical we'd be able to do as he suggests.
It does seem worth considering though. If it can't be a hard parse error
but we agree many/most cases are problematic, perhaps adding detecting this
to the static checks that R CMD CHECK performs is another way forward.
Best,
~G
On Fri, Nov 20, 2020 at 1:34 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
I'm not thinking of complicated cases.
This happened to me in a function that returns 10 minute slots
slot <- function (seconds) {
return (seconds %/% 600) * 600
}
Obviously I found the issue while debugging and corrected my code with
surrounding parenthesis, but I was surprised that the R parser did not catch
this syntactic error.
This is especially poignant when we have to switch between languages like
python where the original line would produce the desired result.
Mateo.
--
Mateo Obregón.
On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:
> Hi all,
>
> I can confirm this occurs for me as well.
>
> The one thing that comes to mind is that there are certain larger
> expressions that contain calls to return which we absolutely don't want to
> be an error, e.g
>
> if(somestuff)
> return(TRUE)
>
>
> That said, the actual expression Mateo pointed out certainly does look like
> an error (it definitely isn't going to do what the developer intended).
>
> I haven't looked at the parser much, to be honest. I assume there is
> perhaps enough differentiation of if/else that return() could be allowed
> within that but not inside a larger expression without it?
>
> There would be things that are legal (though horrifying) now that would
> stop working though, such as:
>
> f = function(a) {
>
> ret = switch(a,
>
> "1"= return("haha got 1!"),
>
> "2" = "regular ole 2")
>
> ret
>
> }
>
>
> Whether it would be a problem or not that such insanity wouldn't work is
> less clear. Are there valid non-if embedded return() cases that are
> important to allow? If so (and if they're not differentiated by the parser,
> which I somewhat doubt switch is, for example, though I'm not certain), I'm
> skeptical we'd be able to do as he suggests.
>
> It does seem worth considering though. If it can't be a hard parse error
> but we agree many/most cases are problematic, perhaps adding detecting this
> to the static checks that R CMD CHECK performs is another way forward.
>
> Best,
> ~G
>
> On Fri, Nov 20, 2020 at 1:34 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@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
FWIW, 'R CMD check --as-cran' in R-devel checks for "bogus return"
statements but I think that's only for the case when one forgets the
parentheses, e.g. 'return' instead of 'return()'.
I don't think it catches this case but I'm also not sure. Though, I can
imagine it might be possible to enhance the current check to include also
this case.
It could be that setting _R_CHECK_BOGUS_RETURN_=true will enable this check
also in earlier versions in R; not sure when it was introduced.
/Henrik
On Fri, Nov 20, 2020, 13:58 Gabriel Becker wrote:
> Hi all,
>
> I can confirm this occurs for me as well.
>
> The one thing that comes to mind is that there are certain larger
> expressions that contain calls to return which we absolutely don't want to
> be an error, e.g
>
> if(somestuff)
> return(TRUE)
>
>
> That said, the actual expression Mateo pointed out certainly does look like
> an error (it definitely isn't going to do what the developer intended).
>
> I haven't looked at the parser much, to be honest. I assume there is
> perhaps enough differentiation of if/else that return() could be allowed
> within that but not inside a larger expression without it?
>
> There would be things that are legal (though horrifying) now that would
> stop working though, such as:
>
> f = function(a) {
>
> ret = switch(a,
>
> "1"= return("haha got 1!"),
>
> "2" = "regular ole 2")
>
> ret
>
> }
>
>
> Whether it would be a problem or not that such insanity wouldn't work is
> less clear. Are there valid non-if embedded return() cases that are
> important to allow? If so (and if they're not differentiated by the parser,
> which I somewhat doubt switch is, for example, though I'm not certain), I'm
> skeptical we'd be able to do as he suggests.
>
> It does seem worth considering though. If it can't be a hard parse error
> but we agree many/most cases are problematic, perhaps adding detecting this
> to the static checks that R CMD CHECK performs is another way forward.
>
> Best,
> ~G
>
> On Fri, Nov 20, 2020 at 1:34 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@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] return (x+1) * 1000
Hi all,
I can confirm this occurs for me as well.
The one thing that comes to mind is that there are certain larger
expressions that contain calls to return which we absolutely don't want to
be an error, e.g
if(somestuff)
return(TRUE)
That said, the actual expression Mateo pointed out certainly does look like
an error (it definitely isn't going to do what the developer intended).
I haven't looked at the parser much, to be honest. I assume there is
perhaps enough differentiation of if/else that return() could be allowed
within that but not inside a larger expression without it?
There would be things that are legal (though horrifying) now that would
stop working though, such as:
f = function(a) {
ret = switch(a,
"1"= return("haha got 1!"),
"2" = "regular ole 2")
ret
}
Whether it would be a problem or not that such insanity wouldn't work is
less clear. Are there valid non-if embedded return() cases that are
important to allow? If so (and if they're not differentiated by the parser,
which I somewhat doubt switch is, for example, though I'm not certain), I'm
skeptical we'd be able to do as he suggests.
It does seem worth considering though. If it can't be a hard parse error
but we agree many/most cases are problematic, perhaps adding detecting this
to the static checks that R CMD CHECK performs is another way forward.
Best,
~G
On Fri, Nov 20, 2020 at 1:34 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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] return (x+1) * 1000
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
