Skip to content

return (x+1) * 1000

17 messages · Gabriel Becker, Henrik Bengtsson, Bill Dunlap +5 more

Original
Mateo Obregón
# 
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
}
[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.
Gabriel Becker
# 
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:

  
  


  


      

    

    

      
      

        


  

        

      Henrik Bengtsson
    

    

      
      #
    

  


  

      
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:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Mateo Obregón
    

    

      
      #
    

  


  

      
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:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 20/11/2020 5:16 p.m., Henrik Bengtsson wrote:

            

      
      
      
    

        
It's quite recent (August of this year):  see 
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17180.

Duncan Murdoch

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Bill Dunlap
    

    

      
      #
    

  


  

      
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:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 20/11/2020 5:36 p.m., Mateo Obreg?n wrote:

            

      
      
      
    

        
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 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:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Dénes Tóth
    

    

      
      #
    

  


  

      
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:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Gabriel Becker
    

    

      
      #
    

  


  

      
And the related:

            

      
      
      
    

        
[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:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Dénes Tóth
    

    

      
      #
    

  


  

      
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:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Henrik Bengtsson
    

    

      
      #
    

  


  

      
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 <toth.denes at kogentum.hu> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
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

        
<henrik.bengtsson at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 20/11/2020 5:58 p.m., Mateo Obreg?n wrote:

            

      
      
      
    

        
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

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Jan T. Kim
    

    

      
      #
    

  


  

      
On Fri, Nov 20, 2020 at 02:48:11PM -0800, Bill Dunlap wrote:

            

      
      
      
    

        
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.

            

      
      
      
    

        
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

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 20/11/2020 7:01 p.m., Ben Bolker wrote:

            

      
      
      
    

        
No, it's commonly nested within an if() expression, and could appear 
anywhere else.

  (2) apply it to some

            

      
      
      
    

        
I did that, in the bug report #17180 I cited.  In 2016 it appeared to be 
misused in about 100 packages.

(3) if so,

            

      
      
      
    

        
That was done this year.

Duncan Murdoch

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
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 <murdoch.duncan at gmail.com> wrote: