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.schumac...@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.schumac...@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@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
