> 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 arro
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
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
> sufficienc
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
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(
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() i
> 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
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 custo
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
b
