Displaying 7 results from an estimated 7 matches for "obregonmateo".
2020 Nov 20
4
return (x+1) * 1000
...onsidering 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) {
> >
>...
2020 Nov 20
0
return (x+1) * 1000
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:
> 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 correc...
2020 Nov 20
5
return (x+1) * 1000
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
2020 Nov 20
1
return (x+1) * 1000
...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) {
> > ret...
2020 Nov 20
1
return (x+1) * 1000
...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:
>...
2020 Nov 20
0
return (x+1) * 1000
...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)
> [...
2020 Nov 20
0
return (x+1) * 1000
...an'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 <- func...