Re: [Rd] detect ->
Dear Bill,
I already tried this, and it would have been great as (currently) the
sufficiency relation is precisely "=>"... but:
foo <- function(x) return(substitute(x))
foo(A => B)
Error: unexpected '>' in "foo(A =>"
It seems that "=>" is a syntactic error for the R parser, while "<=" is not
because it denotes less than or equal.
Now, if I could find a way to define "=>" as a standalone operator, and
convince the R parser to bypass that error, it would solve everything. If this
is not possible, I am back to detecting "->".
Best,
Adrian
> On 13 Apr 2020, at 19:19, William Dunlap wrote:
>
> Using => and <= instead of -> and <- would make things easier, although the
> precedence would be different.
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Mon, Apr 13, 2020 at 1:43 AM Adrian Dușa wrote:
> Thank you for your replies, this actually has little to do with the regular R
> code but more to signal what in my package QCA is referred to as a necessity
> relation A <- B (A is necessary for B) and sufficiency A -> B (A is
> sufficient for B).
>
> If switched by the parser, A -> B becomes B <- A which makes B necessary for
> A, while the intention is to signal sufficiency for B.
>
> Capturing in a quoted string is trivial, but I am now experimenting with
> substitute() to allow unquoted expressions.
>
> This is especially useful when selecting A and B from the columns of a data
> frame, using: c(A, B) instead of c("A", "B") with a lot more quotes for more
> complex expressions using more columns.
>
> I would be grateful for any pointer to a project that processes the code
> while it is still raw text. I could maybe learn from their code and adapt to
> my use case.
>
> Best wishes,
> Adrian
>
> > On 13 Apr 2020, at 11:23, Gabriel Becker wrote:
> >
> > Adrian,
> >
> > Indeed, this has come up in a few places, but as Gabor says, there is no
> > such thing as right hand assignment at any point after parsing is complete.
> >
> > This means the only feasible way to detect it, which a few projects do I
> > believe, is process the code while it is still raw text, before it goes
> > into the parser, and have clever enough regular expressions.
> >
> > The next question, then, is why are you trying to detect right assignment.
> > Doing so can be arguably useful fo linting, its true. Otherwise, though,
> > because its not really a "real thing" when the R code is being executed,
> > its not something thats generally meaningful to detect in most cases.
> >
> > Best,
> > ~G
> >
> > On Mon, Apr 13, 2020 at 12:52 AM Gábor Csárdi
> > wrote:
> > That parser already flips -> to <- before creating the parse tree.
> >
> > Gabor
> >
> > On Mon, Apr 13, 2020 at 8:39 AM Adrian Dușa wrote:
> > >
> > > I searched and tried for hours, to no avail although it looks simple.
> > >
> > > (function(x) substitute(x))(A <- B)
> > > #A <- B
> > >
> > > (function(x) substitute(x))(A -> B)
> > > # B <- A
> > >
> > > In the first example, A occurs on the LHS, but in the second example A is
> > > somehow evaluated as if it occured on the RHS, despite my understanding
> > > that substitute() returns the unevaluated parse tree.
> > >
> > > Is there any way, or is it even possible to detect the right hand
> > > assignment, to determine whether A occurs on the LHS?
> > >
> > > Thanks in advance for any hint,
> > > Adrian
> > >
> > > —
> > > Adrian Dusa
> > > University of Bucharest
> > > Romanian Social Data Archive
> > > Soseaua Panduri nr. 90-92
> > > 050663 Bucharest sector 5
> > > Romania
> > > https://adriandusa.eu
> > >
> > > __
> > > 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
>
> —
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr. 90-92
> 050663 Bucharest sector 5
> Romania
> https://adriandusa.eu
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
—
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] detect ->
On Wed, 15 Apr 2020 10:41:41 +0300 Adrian Dușa wrote: > Now, if I could find a way to define "=>" as a standalone operator, > and convince the R parser to bypass that error, it would solve > everything. If this is not possible, I am back to detecting "->". Just to confirm, are you avoiding custom %operators% because of two extra percent characters one would have to type per operator? -- Best regards, Ivan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] detect ->
> On 15 Apr 2020, at 13:20, Ivan Krylov wrote: > > On Wed, 15 Apr 2020 10:41:41 +0300 > Adrian Dușa wrote: > >> Now, if I could find a way to define "=>" as a standalone operator, >> and convince the R parser to bypass that error, it would solve >> everything. If this is not possible, I am back to detecting "->". > > Just to confirm, are you avoiding custom %operators% because of two > extra percent characters one would have to type per operator? Yes, that's right. The "->" operator is the standard way to signal sufficiency into a SOP (sum of products) expression, something like: A~BC + BC~D + E -> Y This is consistently used in many books and articles, and currently the standard when quoted: "A~BC + BC~D + E -> Y" To require using the %% notation in unquoted strings would make the SOP expression different from the quoted one, which is likely to create confusion: A~BC + BC~D + E %->% Y If detecting "->" proves to be impossible, then I will probably have no choice but to stick with quoted expressions. I am just hoping the collective knowledge here would make this possible, though. Best, Adrian — Adrian Dusa University of Bucharest Romanian Social Data Archive Soseaua Panduri nr. 90-92 050663 Bucharest sector 5 Romania https://adriandusa.eu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path
I think application-specific normalization is actually the right thing to do, because the behavior of normalizePath() is too system-specific and too unreliable. That is not a deficiency of R, the same problem exists on other systems I've spent too much time recently working on normalizePath() implementation on Windows and looking how other systems do it, the implementations are very similar, and the documentation often less detailed on the limitations. As the R documentation says, path normalization is meant for displaying a user-understandable path name in messages and for comparison (e.g. whether two paths refer to the same file, possibly also for their canonical location, mapping some permissions to directories). However, as it also says, it is only best-effort. The resulting path may not be canonical. It may not be pretty (not "user-understandable"). As it may not be canonical, comparing normalized paths e.g. to decide whether they refer to the same file may not be reliable. Again, this is not a limitation of R, but a consequence of file-system complexities and also differences between platforms. The scope for use of normalizePath() is hence very small and only if one can be happy with the "best-effort". For anything reliable, one should try to use something specific for the task, but with well defined behavior. If say just concatenating the current working directory and a relative path provides the desired behavior in a specific situation, it is best to just do it that way. In some cases normalization is easily avoidable by say opening a file sooner rather than later (e.g. the use case of Dean in the bug report). To find out if two path names refer to the same file, with sufficient permissions there are better ways both on Unix and Windows (though maybe not provided by R base packages). Disabling symlinks is impossible/infeasible, that would mean re-implementing the normalization from scratch inside R, without using the OS-level functions (realpath, GetFinalPathNameByHandle), with different error behavior on many details, etc, and the result would be atypical for both Unix (where realpath is normally used for normalization) and Windows platforms (where new language runtimes use GetFinalPathNameByHandle, now including R). Best Tomas On 4/14/20 9:51 PM, Gabriel Becker wrote: If we are fiddling with normalizePath, having a way of not following symlinks (otheer than ~) would be useful as well. I had to write normalizePath2 in switchr for a specific on-the-ground need to NOT go down all he way to physical paths on a remote compute system because of how IT handled implementing constant pathing on top of swapping out hardware, and I can't imagine i'm the only one who has ever faced such an issue. ~G On Tue, Apr 14, 2020 at 10:03 AM Dean Attali wrote: This request stems off a bug report I posted https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17757 where it was determined the current behaviour is as expected. To recap: when given a real file, normalizePath() always* returns the full absolute path. When given a non-existent file, normalizePath() returns a full path on Windows but it returns the input on other systems*. I'd argue that there are benefits to being able to reliably and consistently get a full path, regardless of whether the file exists or not. In order to not break existing behaviour, I propose adding an argument `absolute = FALSE` that will attempt to return an absolute path when the argument is set to TRUE. I don't have any evidence for this claim, but I believe that others who use this function would expect, like I did, that an absolute path is returned regardless of the file state. I understand the documentation is correct because it warns the absolute path may not be returned, but I believe it would be a useful feature to support. * I've tested this on Win7, Win10, two versions of MacOS, ubuntu. This behaviour may not be true in other OSes [[alternative HTML version deleted]] __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path
The fs[1] function `fs::path_abs()` does what I believe you were
expecting `normalizePath()` to do in this case. e.g.
setwd("~")
normalizePath("foo/bar")
#> Warning in normalizePath("foo/bar") :
#> path[1]="foo/bar": No such file or directory
#> [1] "foo/bar"
fs::path_abs("foo/bar")
#> /Users/jhester/foo/bar
[1]: https://CRAN.R-project.org/package=fs
On Tue, Apr 14, 2020 at 1:03 PM Dean Attali wrote:
>
> This request stems off a bug report I posted
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17757 where it was
> determined the current behaviour is as expected.
>
> To recap: when given a real file, normalizePath() always* returns the full
> absolute path. When given a non-existent file, normalizePath() returns a
> full path on Windows but it returns the input on other systems*. I'd argue
> that there are benefits to being able to reliably and consistently get a
> full path, regardless of whether the file exists or not. In order to not
> break existing behaviour, I propose adding an argument `absolute = FALSE`
> that will attempt to return an absolute path when the argument is set to
> TRUE. I don't have any evidence for this claim, but I believe that others
> who use this function would expect, like I did, that an absolute path is
> returned regardless of the file state. I understand the documentation is
> correct because it warns the absolute path may not be returned, but I
> believe it would be a useful feature to support.
>
>
> * I've tested this on Win7, Win10, two versions of MacOS, ubuntu. This
> behaviour may not be true in other OSes
>
> [[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
[Rd] Add a new environment variable switch for the 'large version' check
If you test a package with `R CMD check --as-cran` one of the
'incoming' checks is for a large version number, it gives a NOTE like
this
* checking CRAN incoming feasibility ... NOTE
Maintainer: ‘Jim Hester ’
Version contains large components (0.0.0.9000)
This is a useful check when packages are submitted to CRAN because it
catches these large version components, which typically are reserved
for development versions of packages.
However when checking packages during development it is often expected
to have these large versions, so this note can be confusing for those
new to package development.
Currently the only way to turn off this particular check is to turn
off _all_ of the CRAN incoming checks.
The following patch (also attached) adds an environment variable that
can be used to disable just this check, which would allow users to
disable it if they expect to be using a large version. The default
behavior (and CRAN's usage) would remain unchanged.
diff --git a/src/library/tools/R/QC.R b/src/library/tools/R/QC.R
index 062722127a..64acd72c5e 100644
--- a/src/library/tools/R/QC.R
+++ b/src/library/tools/R/QC.R
@@ -6963,7 +6963,9 @@ function(dir, localOnly = FALSE)
if(grepl("(^|[.-])0[0-9]+", ver))
out$version_with_leading_zeroes <- ver
unlisted_version <- unlist(package_version(ver))
-if(any(unlisted_version >= 1234 & unlisted_version !=
as.integer(format(Sys.Date(), "%Y"
+if(any(unlisted_version >= 1234 & unlisted_version !=
as.integer(format(Sys.Date(), "%Y"))) &&
+
!config_val_to_logical(Sys.getenv("_R_CHECK_CRAN_INCOMING_SKIP_LARGE_VERSION_",
+ "FALSE")))
out$version_with_large_components <- ver
.aspell_package_description_for_CRAN <- function(dir, meta = NULL) {
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] detect ->
You are right. >= is not as evocative as =>. Perhaps > and < would do?
%=>% and %<=% would work.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Wed, Apr 15, 2020 at 12:41 AM Adrian Dușa wrote:
> Dear Bill,
>
> I already tried this, and it would have been great as (currently) the
> sufficiency relation is precisely "=>"... but:
>
> foo <- function(x) return(substitute(x))
> foo(A => B)
> Error: unexpected '>' in "foo(A =>"
>
> It seems that "=>" is a syntactic error for the R parser, while "<=" is
> not because it denotes less than or equal.
>
> Now, if I could find a way to define "=>" as a standalone operator, and
> convince the R parser to bypass that error, it would solve everything. If
> this is not possible, I am back to detecting "->".
>
> Best,
> Adrian
>
>
> > On 13 Apr 2020, at 19:19, William Dunlap wrote:
> >
> > Using => and <= instead of -> and <- would make things easier, although
> the precedence would be different.
> >
> > Bill Dunlap
> > TIBCO Software
> > wdunlap tibco.com
> >
> >
> > On Mon, Apr 13, 2020 at 1:43 AM Adrian Dușa
> wrote:
> > Thank you for your replies, this actually has little to do with the
> regular R code but more to signal what in my package QCA is referred to as
> a necessity relation A <- B (A is necessary for B) and sufficiency A -> B
> (A is sufficient for B).
> >
> > If switched by the parser, A -> B becomes B <- A which makes B necessary
> for A, while the intention is to signal sufficiency for B.
> >
> > Capturing in a quoted string is trivial, but I am now experimenting with
> substitute() to allow unquoted expressions.
> >
> > This is especially useful when selecting A and B from the columns of a
> data frame, using: c(A, B) instead of c("A", "B") with a lot more quotes
> for more complex expressions using more columns.
> >
> > I would be grateful for any pointer to a project that processes the code
> while it is still raw text. I could maybe learn from their code and adapt
> to my use case.
> >
> > Best wishes,
> > Adrian
> >
> > > On 13 Apr 2020, at 11:23, Gabriel Becker
> wrote:
> > >
> > > Adrian,
> > >
> > > Indeed, this has come up in a few places, but as Gabor says, there is
> no such thing as right hand assignment at any point after parsing is
> complete.
> > >
> > > This means the only feasible way to detect it, which a few projects do
> I believe, is process the code while it is still raw text, before it goes
> into the parser, and have clever enough regular expressions.
> > >
> > > The next question, then, is why are you trying to detect right
> assignment. Doing so can be arguably useful fo linting, its true.
> Otherwise, though, because its not really a "real thing" when the R code is
> being executed, its not something thats generally meaningful to detect in
> most cases.
> > >
> > > Best,
> > > ~G
> > >
> > > On Mon, Apr 13, 2020 at 12:52 AM Gábor Csárdi
> wrote:
> > > That parser already flips -> to <- before creating the parse tree.
> > >
> > > Gabor
> > >
> > > On Mon, Apr 13, 2020 at 8:39 AM Adrian Dușa
> wrote:
> > > >
> > > > I searched and tried for hours, to no avail although it looks simple.
> > > >
> > > > (function(x) substitute(x))(A <- B)
> > > > #A <- B
> > > >
> > > > (function(x) substitute(x))(A -> B)
> > > > # B <- A
> > > >
> > > > In the first example, A occurs on the LHS, but in the second example
> A is somehow evaluated as if it occured on the RHS, despite my
> understanding that substitute() returns the unevaluated parse tree.
> > > >
> > > > Is there any way, or is it even possible to detect the right hand
> assignment, to determine whether A occurs on the LHS?
> > > >
> > > > Thanks in advance for any hint,
> > > > Adrian
> > > >
> > > > —
> > > > Adrian Dusa
> > > > University of Bucharest
> > > > Romanian Social Data Archive
> > > > Soseaua Panduri nr. 90-92
> > > > 050663 Bucharest sector 5
> > > > Romania
> > > > https://adriandusa.eu
> > > >
> > > > __
> > > > 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
> >
> > —
> > Adrian Dusa
> > University of Bucharest
> > Romanian Social Data Archive
> > Soseaua Panduri nr. 90-92
> > 050663 Bucharest sector 5
> > Romania
> > https://adriandusa.eu
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> —
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr. 90-92
> 050663 Bucharest sector 5
> Romania
> https://adriandusa.eu
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path
Thanks Tomas - I can easily believe that other systems have much less
documentation on this issue! Thanks for you work on this.
I try to stick with base packages when possible, but if the `fs` package
provides this functionality then I'm happy to use that in this case, thanks
Jim.
On Wed, 15 Apr 2020 at 10:06, Jim Hester wrote:
> The fs[1] function `fs::path_abs()` does what I believe you were
> expecting `normalizePath()` to do in this case. e.g.
>
> setwd("~")
> normalizePath("foo/bar")
> #> Warning in normalizePath("foo/bar") :
> #> path[1]="foo/bar": No such file or directory
> #> [1] "foo/bar"
>
> fs::path_abs("foo/bar")
> #> /Users/jhester/foo/bar
>
> [1]: https://CRAN.R-project.org/package=fs
>
>
> On Tue, Apr 14, 2020 at 1:03 PM Dean Attali wrote:
> >
> > This request stems off a bug report I posted
> > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17757 where it was
> > determined the current behaviour is as expected.
> >
> > To recap: when given a real file, normalizePath() always* returns the
> full
> > absolute path. When given a non-existent file, normalizePath() returns a
> > full path on Windows but it returns the input on other systems*. I'd
> argue
> > that there are benefits to being able to reliably and consistently get a
> > full path, regardless of whether the file exists or not. In order to not
> > break existing behaviour, I propose adding an argument `absolute = FALSE`
> > that will attempt to return an absolute path when the argument is set to
> > TRUE. I don't have any evidence for this claim, but I believe that others
> > who use this function would expect, like I did, that an absolute path is
> > returned regardless of the file state. I understand the documentation is
> > correct because it warns the absolute path may not be returned, but I
> > believe it would be a useful feature to support.
> >
> >
> > * I've tested this on Win7, Win10, two versions of MacOS, ubuntu. This
> > behaviour may not be true in other OSes
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 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] detect ->
> On 15 Apr 2020, at 18:13, William Dunlap wrote: > > You are right. >= is not as evocative as =>. Perhaps > and < would do? > %=>% and %<=% would work. I thought about > and < too, but as you rightly observed > is way less evocative as => There is a certain level of clarity which an arrow like sign offers, and people consistently use an arrow in quoted expressions. In addition anything else, whether > or %=>%, would make an unquoted expression different from the standard quoted one, and that could potentially create confusion. Best wishes, Adrian — Adrian Dusa University of Bucharest Romanian Social Data Archive Soseaua Panduri nr. 90-92 050663 Bucharest sector 5 Romania https://adriandusa.eu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
