[Rd] return (x+1) * 1000

[Duncan Murdoch]

On 20/11/2020 5:58 p.m., Mateo Obregón wrote:
> 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.

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

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