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