[Rd] return (x+1) * 1000

Bill Dunlap w||||@mwdun|@p @end|ng |rom gm@||@com
Fri Nov 20 23:48:11 CET 2020


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

	[[alternative HTML version deleted]]



More information about the R-devel mailing list