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 <obregonma...@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@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
