Hi,
thx for the reply. Unfortunately that is not a simplified version of the
problem. You have a function, call it and get the result (numeric in,
numeric out in that case). For simplicity lets use the "return" case:
##
foobar<-function(x) { return(sqrt(x)) }(2)
##
which is a function (numeric in, numeric out) which is defined, then
gets called and the return value is a function (with an appendix of
"(2)" which gets ignored), not the numeric.
In my opinion the result of the expression above should be a numeric
(1.41... in this case) or an parser error because of ambiguities.
e.g. in comparison with node.js
##
function(x){
return(2*x)
}(2);
##
leads to
##
SyntaxError: Unexpected token (
##
Or Haskell (and basically every complete functional languange)
##
(\x -> 2*x) 2
##
which leads to 4 (... okay, that is not comparable because here the
parenthesis make a closure which also works in R or node.js).
However, I think it's weird that
> ( function(x) { return(2*x) } ( 2 ) ) (3)
is a legal statement which results to 6 and that the "(2)" is
basically
ignored by the parser.
Furthermore it is very strange, that
##
f1<-function(x) { print(2*x) }(2)
f1(3)
##
does the command and gives an error ("attempt to apply non-function")
and
##
f2<-function(x) { return(2*x) }(2)
f2(3)
##
is perfectly fine. Thus the return statement changes the interpretation
as a function? Or do I miss something?
Best wishes
Wilm
Am 21.10.2016 um 17:00 schrieb William Dunlap:> Here is a simplified version of your problem
> > { sqrt }(c(2,4,8))
> [1] 1.414214 2.000000 2.828427
> Do you want that to act differently?
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com <http://tibco.com>
>
> On Fri, Oct 21, 2016 at 6:10 AM, Wilm Schumacher
> <wilm.schumacher at gmail.com <mailto:wilm.schumacher at
gmail.com>> wrote:
>
> Hi,
>
> I hope this is the correct list for my question. I found a wired
> behaviour of my R installation on the evaluation of anonymous
> functions.
>
> minimal working example
>
> ###
> f<-function(x) {
> print( 2*x )
> }(2)
>
> class(f)
>
> f(3)
>
> f<-function(x) {
> print( 2*x )
> }(4)(5)
>
> f(6)
> ###
>
> leads to
>
> ###
> > f<-function(x) {
> + print( 2*x )
> + }(2)
> >
> > class(f)
> [1] "function"
> >
> > f(3)
> [1] 6
> Error in f(3) : attempt to apply non-function
> >
> > f<-function(x) {
> + print( 2*x )
> + }(4)(5)
> >
> > f(6)
> [1] 12
> Error in f(6) : attempt to apply non-function
>
> ###
>
> is this a bug or desired behavior? Using parenthesis of coures
> solves the problem. However, I think the operator precedence could
> be the problem here. I looked at the "./src/main/gram.y" and
I
> think that the line 385
> | FUNCTION '(' formlist ')' cr expr_or_assign
%prec LOW
> should be of way higher precedence. But I cannot forsee the side
> effects of that (which could be horrible in that case).
>
> If this is the desired behaviour and not a bug, I'm very
> interested in the rational behind that.
>
> Best wishes,
>
> Wilm
>
> ps:
>
> $ R --version
> R version 3.3.1 (2016-06-21) -- "Bug in Your Hair"
>
> ______________________________________________
> R-devel at r-project.org <mailto:R-devel at r-project.org>
mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> <https://stat.ethz.ch/mailman/listinfo/r-devel>
>
>
[[alternative HTML version deleted]]
You might find it useful to look at what body() shows you for your example and to think about what return does. Best, luke On Fri, 21 Oct 2016, Wilm Schumacher wrote:> Hi, > > thx for the reply. Unfortunately that is not a simplified version of the > problem. You have a function, call it and get the result (numeric in, > numeric out in that case). For simplicity lets use the "return" case: > > ## > foobar<-function(x) { return(sqrt(x)) }(2) > ## > which is a function (numeric in, numeric out) which is defined, then > gets called and the return value is a function (with an appendix of > "(2)" which gets ignored), not the numeric. > > In my opinion the result of the expression above should be a numeric > (1.41... in this case) or an parser error because of ambiguities. > > e.g. in comparison with node.js > > ## > function(x){ > return(2*x) > }(2); > ## > > leads to > > ## > SyntaxError: Unexpected token ( > ## > > Or Haskell (and basically every complete functional languange) > ## > (\x -> 2*x) 2 > ## > which leads to 4 (... okay, that is not comparable because here the > parenthesis make a closure which also works in R or node.js). > > However, I think it's weird that > > > ( function(x) { return(2*x) } ( 2 ) ) (3) > > is a legal statement which results to 6 and that the "(2)" is basically > ignored by the parser. > > Furthermore it is very strange, that > > ## > f1<-function(x) { print(2*x) }(2) > f1(3) > ## > does the command and gives an error ("attempt to apply non-function") and > ## > f2<-function(x) { return(2*x) }(2) > f2(3) > ## > is perfectly fine. Thus the return statement changes the interpretation > as a function? Or do I miss something? > > Best wishes > > Wilm > > Am 21.10.2016 um 17:00 schrieb William Dunlap: >> Here is a simplified version of your problem >> > { sqrt }(c(2,4,8)) >> [1] 1.414214 2.000000 2.828427 >> Do you want that to act differently? >> >> >> Bill Dunlap >> TIBCO Software >> wdunlap tibco.com <http://tibco.com> >> >> On Fri, Oct 21, 2016 at 6:10 AM, Wilm Schumacher >> <wilm.schumacher at gmail.com <mailto:wilm.schumacher at gmail.com>> wrote: >> >> Hi, >> >> I hope this is the correct list for my question. I found a wired >> behaviour of my R installation on the evaluation of anonymous >> functions. >> >> minimal working example >> >> ### >> f<-function(x) { >> print( 2*x ) >> }(2) >> >> class(f) >> >> f(3) >> >> f<-function(x) { >> print( 2*x ) >> }(4)(5) >> >> f(6) >> ### >> >> leads to >> >> ### >> > f<-function(x) { >> + print( 2*x ) >> + }(2) >> > >> > class(f) >> [1] "function" >> > >> > f(3) >> [1] 6 >> Error in f(3) : attempt to apply non-function >> > >> > f<-function(x) { >> + print( 2*x ) >> + }(4)(5) >> > >> > f(6) >> [1] 12 >> Error in f(6) : attempt to apply non-function >> >> ### >> >> is this a bug or desired behavior? Using parenthesis of coures >> solves the problem. However, I think the operator precedence could >> be the problem here. I looked at the "./src/main/gram.y" and I >> think that the line 385 >> | FUNCTION '(' formlist ')' cr expr_or_assign %prec LOW >> should be of way higher precedence. But I cannot forsee the side >> effects of that (which could be horrible in that case). >> >> If this is the desired behaviour and not a bug, I'm very >> interested in the rational behind that. >> >> Best wishes, >> >> Wilm >> >> ps: >> >> $ R --version >> R version 3.3.1 (2016-06-21) -- "Bug in Your Hair" >> >> ______________________________________________ >> R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> <https://stat.ethz.ch/mailman/listinfo/r-devel> >> >> > > > [[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
Are you saying that
f1 <- function(x) log(x)
f2 <- function(x) { log } (x)
should act differently?
Using 'return' complicates the matter, because it affects evaluation,
not
parsing.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Oct 21, 2016 at 8:43 AM, Wilm Schumacher <wilm.schumacher at
gmail.com>
wrote:
> Hi,
>
> thx for the reply. Unfortunately that is not a simplified version of the
> problem. You have a function, call it and get the result (numeric in,
> numeric out in that case). For simplicity lets use the "return"
case:
> ##
> foobar<-function(x) { return(sqrt(x)) }(2)
> ##
> which is a function (numeric in, numeric out) which is defined, then gets
> called and the return value is a function (with an appendix of
"(2)" which
> gets ignored), not the numeric.
>
> In my opinion the result of the expression above should be a numeric
> (1.41... in this case) or an parser error because of ambiguities.
>
> e.g. in comparison with node.js
> ##
> function(x){
> return(2*x)
> }(2);
> ##
>
> leads to
> ##
> SyntaxError: Unexpected token (
> ##
>
> Or Haskell (and basically every complete functional languange)
> ##
> (\x -> 2*x) 2
> ##
> which leads to 4 (... okay, that is not comparable because here the
> parenthesis make a closure which also works in R or node.js).
>
> However, I think it's weird that
>
> > ( function(x) { return(2*x) } ( 2 ) ) (3)
>
> is a legal statement which results to 6 and that the "(2)" is
basically
> ignored by the parser.
>
> Furthermore it is very strange, that
> ##
> f1<-function(x) { print(2*x) }(2)
> f1(3)
> ##
> does the command and gives an error ("attempt to apply
non-function") and
> ##
> f2<-function(x) { return(2*x) }(2)
> f2(3)
> ##
> is perfectly fine. Thus the return statement changes the interpretation as
> a function? Or do I miss something?
>
> Best wishes
> Wilm
>
>
> Am 21.10.2016 um 17:00 schrieb William Dunlap:
>
> Here is a simplified version of your problem
> > { sqrt }(c(2,4,8))
> [1] 1.414214 2.000000 2.828427
> Do you want that to act differently?
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Fri, Oct 21, 2016 at 6:10 AM, Wilm Schumacher <
> wilm.schumacher at gmail.com> wrote:
>
>> Hi,
>>
>> I hope this is the correct list for my question. I found a wired
>> behaviour of my R installation on the evaluation of anonymous
functions.
>>
>> minimal working example
>>
>> ###
>> f<-function(x) {
>> print( 2*x )
>> }(2)
>>
>> class(f)
>>
>> f(3)
>>
>> f<-function(x) {
>> print( 2*x )
>> }(4)(5)
>>
>> f(6)
>> ###
>>
>> leads to
>>
>> ###
>> > f<-function(x) {
>> + print( 2*x )
>> + }(2)
>> >
>> > class(f)
>> [1] "function"
>> >
>> > f(3)
>> [1] 6
>> Error in f(3) : attempt to apply non-function
>> >
>> > f<-function(x) {
>> + print( 2*x )
>> + }(4)(5)
>> >
>> > f(6)
>> [1] 12
>> Error in f(6) : attempt to apply non-function
>>
>> ###
>>
>> is this a bug or desired behavior? Using parenthesis of coures solves
the
>> problem. However, I think the operator precedence could be the problem
>> here. I looked at the "./src/main/gram.y" and I think that
the line 385
>> | FUNCTION '(' formlist ')' cr expr_or_assign
%prec LOW
>> should be of way higher precedence. But I cannot forsee the side
effects
>> of that (which could be horrible in that case).
>>
>> If this is the desired behaviour and not a bug, I'm very interested
in
>> the rational behind that.
>>
>> Best wishes,
>>
>> Wilm
>>
>> ps:
>>
>> $ R --version
>> R version 3.3.1 (2016-06-21) -- "Bug in Your Hair"
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
[[alternative HTML version deleted]]
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