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.
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 <obregonmateo at gmail.com>
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 mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
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 <gabembecker at gmail.com> 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 <obregonmateo at gmail.com> > 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 mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
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 <obregonmateo at
gmail.com>
>
> 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 mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
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 mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
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> 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 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 >[[alternative HTML version deleted]]