return (x+1) * 1000

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.