[Rd] return (x+1) * 1000

[Mateo Obregón]

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 using 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 using r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> > 
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel