[R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0

Thank you very much for your comment. 
Could you elaborate how you think that it could interfere with the help
system?
I haven't yet connected the Julia help with the R help, as the R help
system is quite complex and RStudio handles it again differently. So
it's simply like the functions were declared on the command line. They
have no help.
A simply way to print the help for a Julia function, e.g. the function
"first", is to call
juliaEval("@doc first")
This then simply prints the output on the command line.


----------------urspr?ngliche Nachricht-----------------
Von: Jeff Newmiller [jdnewmil at dcn.davis.ca.us]
An: r-package-devel at r-project.org, Duncan Murdoch
[murdoch.duncan at gmail.com], Stefan Lenz IMBI
[lenz at imbi.uni-freiburg.de]
Datum: Mon, 06 Apr 2020 10:51:53 -0700
-------------------------------------------------

One could take the position that the library and require functions

were a mistake 

to begin with and that all contributed packages should be accessed

using ::... or 

one could recognize that these functions are an expected feature of R

at this 

point and then it is not defensible to ban the proposed approach of

importing 

names as Stefan wants to. I don't think it is fair to require this

higher level of 

specificity just because it involves use of attach.

That said, another feature of R packages is the integrated help

system... 

importing Julia functions wholesale may lead to problems with

consistency in 

navigating the help files. IMO it may be justifiable to ban this

particular 

syntactic convenience to maintain some separation in the minds of

users looking 

for help on these new functions, since the syntactic and semantic

structure of 

functions from another language may not align well with normal R

functions. But I 

am not familiar with Julia or Stefan's package or the support it

brings in this 

area... I just disagree with banning a "library" lookalike function

"just 

because" it happens to involve attach.

On April 6, 2020 8:40:12 AM PDT, Duncan Murdoch

<murdoch.duncan at gmail.com> 

wrote:

On 06/04/2020 11:25 a.m., Stefan Lenz IMBI wrote:

Yes, as I wrote earlier, I would like to imitate the behaviour of

loading an R package

juliaUsing("SomeJuliaPackage") # exports myJuliaFunction
myJuliaFunction()

like R:

library("MyRPackage") # exports myRFunction
myRFunction()

I could return an environment, such that the call becomes

attach(juliaUsing("SomeJuliaPackage"))
myJuliaFunction()

I wouldn't use it that way. I'd write it as

sjp <- juliaUsing("SomeJuliaPackage")
sjp$myJuliaFunction()

This is similar to the advice to use pkg::foo() rather than
library(pkg) 
followed by plain foo() in the code.

Duncan Murdoch

But calling juliaUsing(), as it is now, takes care that if a

package

is imported a second time,

the first data base is removed via detach().
This way, users do not have to worry about calling juliaUsing()

mutliple times in a script, same

as R users don't have to worry about calling library() multiple

times.

If you call the code with attach() multiple times and do not

detach,

you get your screen cluttered with

warnings "xxx is masked by xxx".
So I would say it would decrease user-friendliness to return an

environment.

I also want to make explicit, that the call to attach
occurs only once in my code, after creating the environment:

envName <- paste0("JuliaConnectoR:", absoluteModulePath)
if (envName %in% search()) {
detach(envName, character.only = TRUE)
}
attach(funenv, name = envName)

This code is only called by juliaImport() and juliaUsing(), which

aren't called by any other function of

the package
and are supposed to be called directly by the user.

Stefan

----------------urspr?ngliche Nachricht-----------------
Von: Duncan Murdoch [murdoch.duncan at gmail.com]
An: Dirk Eddelbuettel [edd at debian.org], Ben Bolker

[bbolker at gmail.com]

Kopie: List r-package-devel [r-package-devel at r-project.org]
Datum: Mon, 6 Apr 2020 11:00:09 -0400
-------------------------------------------------

On 06/04/2020 10:49 a.m., Dirk Eddelbuettel wrote:

On 6 April 2020 at 08:38, Ben Bolker wrote:
| Just reply to the CRAN maintainers and explain this situation.

It?s

| slightly buried, but the e-mail you received does say:
|
| > If you are fairly certain the rejection is a false positive,

please reply-all to this

| > message and explain.

True, but this misses the "Letter of the law" versus the "Spirit

of

the law".

It might be worth mentioning that use of attach() is seen, to

find

one poor

analogy, pretty much like use of global variables these days.

"Just

because

you could does not mean you should".

See e.g. one of the first google hits for 'r do not use attach'

here:

https://stackoverflow.com/questions/10067680/why-is-it-not-advisable-to-use-attach-in-r-and-what-should-i-use-instead

I don't have a strong opinion on this: the proposed use seems to

be

no

worse than library() or require(). Those are fine for users to

use,

but

are discouraged in a package. If the attach() never happens

without

an

explicit request from the user (and that's what it sounds like),

I'd

say

it's probably okay.

However, there is an easy workaround: just return the environment
without attaching it. Then the user has the choice of attaching

it,

or

using it as a prefix when they call the functions in it. So it's

not

as

though this will destroy the utility of the package if Stefan

isn't

allowed to call attach().

Duncan Murdoch