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 parent token terminal text
## 14 1 1 1 10 14 0 expr FALSE
## 1 1 1 1 1 1 3 SYMBOL_FUNCTION_CALL TRUE c
## 3 1 1 1 1 3 14 expr FALSE
## 2 1 2 1 2 2 14 '(' TRUE
(
## 4 1 3 1 3 4 6 SYMBOL TRUE F
## 6 1 3 1 3 6 14 expr FALSE
## 5 1 4 1 4 5 14 ',' TRUE
,
## 9 1 5 1 9 9 10 NUM_CONST TRUE FALSE
## 10 1 5 1 9 10 14 expr FALSE
## 11 1 10 1 10 11 14 ')' TRUE
)
I would expect that token for F is the same as token for FALSE.
Thank you!
Iago
[[alternative HTML version deleted]]
>From help(F): TRUE and FALSE are reserved <http://127.0.0.1:39090/help/library/base/help/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 <i.gine at pssjd.org> 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 parent token terminal text > ## 14 1 1 1 10 14 0 expr FALSE > ## 1 1 1 1 1 1 3 SYMBOL_FUNCTION_CALL TRUE c > ## 3 1 1 1 1 3 14 expr FALSE > ## 2 1 2 1 2 2 14 '(' TRUE ( > ## 4 1 3 1 3 4 6 SYMBOL TRUE F > ## 6 1 3 1 3 6 14 expr FALSE > ## 5 1 4 1 4 5 14 ',' TRUE , > ## 9 1 5 1 9 9 10 NUM_CONST TRUE FALSE > ## 10 1 5 1 9 10 14 expr FALSE > ## 11 1 10 1 10 11 14 ')' TRUE ) > > I would expect that token for F is the same as token for FALSE. > > > Thank you! > > Iago > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel--------------- John Mount http://www.win-vector.com/ <http://www.win-vector.com/> Our book: Practical Data Science with R http://practicaldatascience.com <http://practicaldatascience.com/> [[alternative HTML version deleted]]
On Wed, 15 Jan 2020 at 15:14, IAGO GIN? V?ZQUEZ <i.gine at pssjd.org> 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 parent token terminal text > ## 14 1 1 1 10 14 0 expr FALSE > ## 1 1 1 1 1 1 3 SYMBOL_FUNCTION_CALL TRUE c > ## 3 1 1 1 1 3 14 expr FALSE > ## 2 1 2 1 2 2 14 '(' TRUE ( > ## 4 1 3 1 3 4 6 SYMBOL TRUE F > ## 6 1 3 1 3 6 14 expr FALSE > ## 5 1 4 1 4 5 14 ',' TRUE , > ## 9 1 5 1 9 9 10 NUM_CONST TRUE FALSE > ## 10 1 5 1 9 10 14 expr FALSE > ## 11 1 10 1 10 11 14 ')' TRUE ) > > I would expect that token for F is the same as token for FALSE.>From the manual:?TRUE? and ?FALSE? are reserved words denoting logical constants in the R language, whereas ?T? and ?F? are global variables whose initial values set to these. I?aki
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)) isTRUE(T) was the reason the code didn't do what it's supposed to do. (Also don't use T as short for "Transpose of my matrix", but that's another hill.) As we've become more strict on the use of T and F in packages, maybe 4.0.0 is a good milestone to finally drop this relic from the past? One can dream... Kind regards Joris On Wed, Jan 15, 2020 at 3:14 PM IAGO GIN? V?ZQUEZ <i.gine at pssjd.org> 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 parent token terminal text > ## 14 1 1 1 10 14 0 expr FALSE > ## 1 1 1 1 1 1 3 SYMBOL_FUNCTION_CALL TRUE c > ## 3 1 1 1 1 3 14 expr FALSE > ## 2 1 2 1 2 2 14 '(' TRUE ( > ## 4 1 3 1 3 4 6 SYMBOL TRUE F > ## 6 1 3 1 3 6 14 expr FALSE > ## 5 1 4 1 4 5 14 ',' TRUE , > ## 9 1 5 1 9 9 10 NUM_CONST TRUE FALSE > ## 10 1 5 1 9 10 14 expr FALSE > ## 11 1 10 1 10 11 14 ')' TRUE ) > > I would expect that token for F is the same as token for FALSE. > > > Thank you! > > Iago > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> ------------------------------- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]]
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 time makes this
workflow relatively longer.
IMO it would be best to warn about T/F symbols during package check,
but not necessarily removing them globally.
On Fri, Jan 17, 2020 at 4:01 PM Joris Meys <jorismeys at gmail.com>
wrote:>
> 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))
> isTRUE(T)
>
> was the reason the code didn't do what it's supposed to do. (Also
don't use
> T as short for "Transpose of my matrix", but that's another
hill.)
>
> As we've become more strict on the use of T and F in packages, maybe
4.0.0
> is a good milestone to finally drop this relic from the past? One can
> dream...
>
> Kind regards
> Joris
>
> On Wed, Jan 15, 2020 at 3:14 PM IAGO GIN? V?ZQUEZ <i.gine at
pssjd.org> 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 parent token terminal
text
> > ## 14 1 1 1 10 14 0 expr FALSE
> > ## 1 1 1 1 1 1 3 SYMBOL_FUNCTION_CALL TRUE
c
> > ## 3 1 1 1 1 3 14 expr FALSE
> > ## 2 1 2 1 2 2 14 '('
TRUE (
> > ## 4 1 3 1 3 4 6 SYMBOL TRUE
F
> > ## 6 1 3 1 3 6 14 expr FALSE
> > ## 5 1 4 1 4 5 14 ','
TRUE ,
> > ## 9 1 5 1 9 9 10 NUM_CONST TRUE
FALSE
> > ## 10 1 5 1 9 10 14 expr FALSE
> > ## 11 1 10 1 10 11 14 ')'
TRUE )
> >
> > I would expect that token for F is the same as token for FALSE.
> >
> >
> > Thank you!
> >
> > Iago
> >
> >
> > [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
>
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
> -------------------------------
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
Possibly Parallel Threads
- Printing chinese characters (UTF-8) on R 3.5.2 -windows 10
- Printing chinese characters (UTF-8) on R 3.5.2 -windows 10
- Printing chinese characters (UTF-8) on R 3.5.2 -windows 10
- The presence/absence of `zone` in POSIXlt depending on time zone as a cause of possible inconsistences?
- A bug understanding F relative to FALSE?