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 [jdnew...@dcn.davis.ca.us] An: r-package-devel@r-project.org, Duncan Murdoch [murdoch.dun...@gmail.com], Stefan Lenz IMBI [l...@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.dun...@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.dun...@gmail.com] >>> An: Dirk Eddelbuettel [e...@debian.org], Ben Bolker >>[bbol...@gmail.com] >>> Kopie: List r-package-devel [r-package-devel@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 >>>> >>>> ______________________________________________ >>>> R-package-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>>> >>> >>> >> >>______________________________________________ >>R-package-devel@r-project.org mailing list >>https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Stefan Lenz Institut für Medizinische Biometrie und Statistik Medizinische Fakultät / Universitätsklinikum Freiburg Postadresse: Stefan-Meier-Str. 26, 79104 Freiburg Tel.: 0761/203-6670 E-Mail: l...@imbi.uni-freiburg.de ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel