[Rd] Package install problem in R-devel under Windows
Hi, Using the latest R-devel under Windows, I've encountered the following problem when trying to install packages at the prompt: >R CMD INSTALL d:\inum_0.1-0.tar.gz * installing to library 'C:\Users\henwin\R\win-library\3.4' * installing *source* package 'inum' ... ** R ** preparing package for lazy loading ** help *** installing help indices ** building package indices ** testing if installed package can be loaded *** arch - i386 Error: '\U' used without hex digits in character string starting "'C:\U" Execution halted *** arch - x64 Error: '\U' used without hex digits in character string starting "'C:\U" Execution halted ERROR: loading failed for 'i386', 'x64' * removing 'C:\Users\henwin\R\win-library\3.4/inum' So, it seems that it doesn't correctly escape the '\' anymore...? However, installing from within Rgui works without a hitch. Also, in latest R-3.3.1patched it works as expected: C:\Program Files\R\R-3.3.1patched\bin>R CMD INSTALL d:\inum_0.1-0.tar.gz * installing to library 'C:/Users/hennil/R/win-library/3.3' * installing *source* package 'inum' ... ** R ** preparing package for lazy loading ** help *** installing help indices ** building package indices ** testing if installed package can be loaded *** arch - i386 *** arch - x64 * DONE (inum) Is this a known issue? Or is it just me...? Henric Winell __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] anonymous function parsing bug?
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
Re: [Rd] anonymous function parsing bug?
Hi,
sry for the double posting. I forgot to mention that this example
###
f<-function(x) {
return( 2*x )
}(2)
class(f)
f(3)
f<-function(x) {
return( 2*x )
}(4)(5)
f(6)
###
leads to
##
> f<-function(x) {
+ return( 2*x )
+ }(2)
>
> class(f)
[1] "function"
>
> f(3)
[1] 6
>
> f<-function(x) {
+ return( 2*x )
+ }(4)(5)
>
> f(6)
[1] 12
##
which is even stranger (at least for me) and contradicts the first
listing imho in behaviour.
Best wishes,
Wilm
Am 21.10.2016 um 15:10 schrieb Wilm Schumacher:
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
Re: [Rd] anonymous function parsing bug?
Here is a simplified version of your problem
> { sqrt }(c(2,4,8))
[1] 1.414214 2.00 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
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
Re: [Rd] anonymous function parsing bug?
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.00 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
> mailto: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
Re: [Rd] anonymous function parsing bug?
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.00 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
mailto: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
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] anonymous function parsing bug?
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] anonymous function parsing bug?
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
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.00 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
Re: [Rd] anonymous function parsing bug?
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.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Oct 21, 2016 at 10:17 AM, Wilm Schumacher 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] anonymous function parsing bug?
> On 21 Oct 2016, at 19:17 , Wilm Schumacher 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. 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).
I think Bill and Luke are failing in trying to make you work out the logic for
yourself...
The point is that
{
some_computation
}(x)
is an expression that evaluates some_computation and applies it as a function
to the argument x (or fails if not a function).
When you define functions, the body can be a single expression, so
f <- function(a)
{
some_computation
}(x)
is effectively the same as
f <- function(a) {
{
some_computation
}(x)
}
where you seem to be expecting
{f <- function(a) {
{
some_computation
}
}(x)
Got it?
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] anonymous function parsing bug?
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
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@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 andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
