Re: [Rd] A bug understanding F relative to FALSE?

2020-01-23 Thread Jan Gorecki
I agree it is not good to have those symbols used in packages, but I found to use those quite often in my developement workflow, which is something like: $ R -q > cc(F) where `cc` is my function to rebuild application to recent state. I use it really often. Having to type FALSE every

Re: [Rd] A bug understanding F relative to FALSE?

2020-01-20 Thread Joris Meys
As others have pointed out, this is expected behaviour. Let me get on that hill I'll die on: it is absolutely not suitable. It is way beyond time to remove T and F as unprotected kind-of-synonyms for TRUE and FALSE, given the amount of times I had to point out that: T <- t(matrix(0:3,nrow=2))

Re: [Rd] A bug understanding F relative to FALSE?

2020-01-17 Thread John Mount
>From help(F): TRUE and FALSE are reserved > words denoting >logical constants in the Rlanguage, whereas T and F are global variables whose >initial values set to these. > On Jan 15, 2020, at 6:13 AM, IAGO GINÉ VÁZQUEZ wrote: > > Hi

Re: [Rd] A bug understanding F relative to FALSE?

2020-01-15 Thread Iñaki Ucar
On Wed, 15 Jan 2020 at 15:14, IAGO GINÉ VÁZQUEZ wrote: > > Hi all, > > Is the next behaviour suitable? > > identical(F,FALSE) > > ## [1] TRUE > > utils::getParseData(parse(text = "c(F,FALSE)", keep.so=rce = TRUE)) > > ##line1 col1 line2 col2 id parenttoken terminal text > ##

[Rd] A bug understanding F relative to FALSE?

2020-01-15 Thread IAGO GINÉ VÁZQUEZ
Hi all, Is the next behaviour suitable? identical(F,FALSE) ## [1] TRUE utils::getParseData(parse(text = "c(F,FALSE)", keep.so=rce = TRUE)) ##line1 col1 line2 col2 id parenttoken terminal text ## 14 11 1 10 14 0 exprFALSE ## 1 1