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 <jorism...@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.g...@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@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
