From luke-tierney at uiowa.edu  Fri Oct 21 23:59:58 2016
From: luke-tierney at uiowa.edu (luke-tierney at uiowa.edu)
Date: Fri, 21 Oct 2016 16:59:58 -0500
Subject: [Rd] anonymous function parsing bug?
In-Reply-To: <CAF8bMcb8PjSv1-aTBP_JXrJBuaEKsSQHuZUifPcNfn9ho9x9UQ@mail.gmail.com>
References: <97dcb35c-9173-5fc6-a499-680a4be15a94@gmail.com>
	<CAF8bMcakY4mDNiFqi2Tj8JeuLXQ74utkrC4J4ArWQLx0LX=E8w@mail.gmail.com>
	<1852931e-89bd-3e9f-934c-2a42361ed414@gmail.com>
	<CAF8bMcaxjGukTYgcOEbQc6XfF51q65CwqWYPzkxaymGBKS-1Ng@mail.gmail.com>
	<1ffe617d-5699-95ee-6846-7741ca75e351@gmail.com>
	<CAF8bMcb8PjSv1-aTBP_JXrJBuaEKsSQHuZUifPcNfn9ho9x9UQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1610211655180.2688@luke-Latitude>

On Fri, 21 Oct 2016, William Dunlap via R-devel wrote:

> Am 21.10.2016 um 18:10 schrieb William Dunlap:
>>
>> Are you saying that
>
>    f1 <- function(x) log(x)
>
>    f2 <- function(x) { log } (x)
>
> should act differently?
>
> yes.
>
>
> But that would mean that {log} would act differently than log.
> I suppose it is a matter of taste, but I say yuck.
>
> As for 'return', don't use it if you want readable code.  It is
> like a goto but worse.  It is never necessary.

As a rule I agree, but one case where return is clearer than the alternative is

repeat {
    ....
    if (...)
       return(...)
}

Complicated nested if expressions are also sometimes clearer using
return as an early breakout.

Best,

luke

>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Fri, Oct 21, 2016 at 10:17 AM, Wilm Schumacher <wilm.schumacher at gmail.com
>> wrote:
>
>> Hi,
>>
>>
>> Am 21.10.2016 um 18:10 schrieb William Dunlap:
>>
>>> Are you saying that
>>>     f1 <- function(x) log(x)
>>>     f2 <- function(x) { log } (x)
>>> should act differently?
>>>
>> yes. Or more precisely: I would expect that. "Should" implies, that I want
>> to change something. I just want to understand the behavior (or file a bug,
>> if this would have been one).
>>
>> As I wrote, in e.g. node.js the pendents to the lines that you wrote are
>> treated differently (the first is a function, the latter is a parsing
>> error).
>>
>> Let's use this example instead:
>> x <- 20
>> f1 <- function(x) { x<-x+1; log(x) }
>> f2 <- function(x) { x<-x+1; log } (x)
>> which act equally.
>>
>> But as the latter is a legal statement, I would read it as
>> f2 <- (function(x) { x<-x+1; log }) (x)
>>
>> thus, I would expect the first to be a function, the latter to be a
>> numeric ( log(20) in this case ).
>>
>>
>> Using 'return' complicates the matter, because it affects evaluation, not
>>> parsing.
>>>
>>
>> But perhaps it illustrates my problem a little better:
>> x <- 20
>> f1 <- function(x) return(log(x))
>> f2 <- function(x) { return(log) } (x)
>>
>> f1(10) is a numeric, f2(10) is the log function. Again: as the latter is a
>> legal statement, I would expect:
>> f2 <- (function(x) { x<-x+1; log }) (x)
>>
>> However, regarding the answers I will try to construct the AST regarding
>> the grammar defined in gramm.y of that statement
>> f2 <- function(x) { x<-x+1; log } (x)
>> to understand what the R interpreter really does.
>>
>> Best wishes,
>>
>> Wilm
>>
>>
>>
>>
>>
>
> 	[[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:   luke-tierney at uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu



[Rd] anonymous function parsing bug?
luke-tierney at uiowa.edu