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

Hi!
Thanks for pointing to the package "namespace".
I experimented with it but I couldn't really figure out how it is supposed to work:

The following code leads to strange errors that I don't understand:

 > nse <- list2env(list(data="x", asdf = 2))
 > namespace::registerNamespace(name = "NewNamespace", env = nse)
 > NewNamespace::asdf
 Error in asNamespace(ns) : not a namespace

It would really be interesting if someone could comment on whether the namespace approach is feasible, how it is supposed to work, and whether/how it would be better than using attach.
Greetings!
Stefan


----------------urspr?ngliche Nachricht-----------------
Von: Joris Meys [Joris.Meys at ugent.be]
An: Stefan Lenz IMBI [lenz at imbi.uni-freiburg.de], Jeff Newmiller [jdnewmil at dcn.davis.ca.us], r-package-devel at r-project.org, Duncan Murdoch [murdoch.duncan at gmail.com]
Datum: Thu, 9 Apr 2020 12:59:23 +0000
-------------------------------------------------


> Hi Stefan,
>
> first of all, thank you for taking the time and effort to link Julia and R. That
> said, I would strongly encourage you to go for a reticulate-like approach.
> There's a good reason for that. Once you start mixing languages, you really want
> to have some indication what code is ran in what language. Especially since I can
> imagine at one point there'll be a Julia function masking an R function of the same
> name, and that is going to cause a world of hurt and confusion.
>
> If you don't like environments, you can try to use namespace functionality.
> There's the "namespace" package that allows you to create one, and some internal
> namespace functions are visible (eg namespaceExport() from base). That's
> going to be the closest to mimicking R packages, but it's beyond my knowledge to
> know how feasible this approach actually is. I hope someone else chimes in,
> especially if this is dangerous for other reasons I overlooked.
>
> Kind regards
> Joris
>
> Joris Meys
> Statistician
> T +32 9 264 61 79
>
> Department Data Analysis and Mathematical Modelling
>
> Campus Coupure, Block A 1st floor 110.050, Coupure links 653, B-9000 Ghent,
> Belgium
> T administration office +32 9 264 59 32
>
> www.ugent.be
>
> e-maildisclaimer
>
>
> ________________________________________
> From: R-package-devel <r-package-devel-bounces at r-project.org> on behalf
> of Stefan Lenz IMBI <lenz at imbi.uni-freiburg.de>
> Sent: Thursday, April 9, 2020 10:41 AM
> To: Jeff Newmiller; r-package-devel at r-project.org; Duncan Murdoch
> Subject: Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission
> JuliaConnectoR 0.5.0
>
> It is important for me to get my package into CRAN.
> I haven't gotten any answer from the CRAN maintainers. I already tried to submit a
> version of the package before some months and haven't gotten any reply then.
> The replies you gave me (thanks to all engaged in the discussion) were mixed.
> I still think that the library-like import is a good feature, but if it is not
> possible to get this package on CRAN with it, I will change it with returning an
> environment like reticulate.
> My question now is:
> So what would be the process how to proceed?
> Is there anybody who can make a decision in such cases?
> Or do I make this decision myself after I lost hope that it will be accepted the way
> it is now?
>
> Stefan
>
>
> ----------------urspr?ngliche Nachricht-----------------
> Von: Jeff Newmiller [jdnewmil at dcn.davis.ca.us]
> An: Stefan Lenz IMBI [lenz at imbi.uni-freiburg.de],
> r-package-devel at r-project.org, Duncan Murdoch
> [murdoch.duncan at gmail.com]
> Datum: Tue, 07 Apr 2020 09:52:52 -0700
> -------------------------------------------------
>
>
>> I did not say "interfere"... I said "problems with consistency". I don't think
>> your wholesale import of functions without corresponding help pages is
>> consistent with the normal use of R, which will make reading R code written with
>> this mechanism in place a painful source of trouble for help forums.
>>
>> On the other hand, if the code is prefaced with an environment name then there will
>> be no expectation that a help page should exist on the part of someone reading that
>> code for the first time. (It will be no less obscure, but at least it won't be
>> misleading.)
>>
>> On April 7, 2020 9:40:02 AM PDT, Stefan Lenz IMBI <lenz at imbi.uni-freiburg.de>
>> wrote:
>>>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
>>>>>>>
>>>>>>> ______________________________________________
>>>>>>> R-package-devel at r-project.org mailing list
>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>______________________________________________
>>>>>R-package-devel at 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 at imbi.uni-freiburg.de
>
> ______________________________________________
> R-package-devel at 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 at imbi.uni-freiburg.de