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

[Stefan Lenz IMBI]

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 using dcn.davis.ca.us]
An: r-package-devel using r-project.org, Duncan Murdoch [murdoch.duncan using gmail.com], Stefan Lenz IMBI [lenz using 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 using 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 using gmail.com]
>>> An: Dirk Eddelbuettel [edd using debian.org], Ben Bolker
>>[bbolker using gmail.com]
>>> Kopie: List r-package-devel [r-package-devel using 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 using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>
>>> 
>>>
>>
>>______________________________________________
>>R-package-devel using 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: lenz using imbi.uni-freiburg.de