Displaying 12 results from an estimated 12 matches for "obreg".
Did you mean:
breg
2020 Nov 20
4
return (x+1) * 1000
...e 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:
> 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
>...
2020 Nov 20
1
return (x+1) * 1000
...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 (se...
2020 Nov 20
5
return (x+1) * 1000
...(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.
2020 Nov 20
2
return (x+1) * 1000
...Nov 20, 2020 at 3:27 PM D?nes T?th <toth.denes at kogentum.hu> wrote:
> 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:
> > 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
> >...
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 d...
2020 Nov 20
0
return (x+1) * 1000
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...
2020 Nov 20
2
return (x+1) * 1000
...gt;
> > 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:
> > > 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...
2020 Nov 20
1
return (x+1) * 1000
...s 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) {...
2020 Nov 21
1
return (x+1) * 1000
...;
>>>> 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:
>>>> > 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
...ble 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
> }
>...
2020 Nov 20
0
return (x+1) * 1000
...toth.denes at kogentum.hu>> wrote:
>
> 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:
> > 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 21
0
return (x+1) * 1000
...ively:
> > >
> > > 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:
> > > > 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:
> > >...