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

Stefan Lenz IMBI |enz @end|ng |rom |mb|@un|-|re|burg@de
Thu Apr 9 17:30:35 CEST 2020

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.

----------------ursprüngliche Nachricht-----------------
Von: Joris Meys [Joris.Meys using ugent.be]
An: Stefan Lenz IMBI [lenz using imbi.uni-freiburg.de], Jeff Newmiller [jdnewmil using dcn.davis.ca.us], r-package-devel using r-project.org, Duncan Murdoch [murdoch.duncan using 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 using r-project.org> on behalf 
> of Stefan Lenz IMBI <lenz using imbi.uni-freiburg.de>
> Sent: Thursday, April 9, 2020 10:41 AM
> To: Jeff Newmiller; r-package-devel using 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 using dcn.davis.ca.us]
> An: Stefan Lenz IMBI [lenz using imbi.uni-freiburg.de], 
> r-package-devel using r-project.org, Duncan Murdoch 
> [murdoch.duncan using 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 using 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
>>>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
>>>> 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
>>>> importing Julia functions wholesale may lead to problems with
>>>consistency in
>>>> navigating the help files. IMO it may be justifiable to ban this
>>>> 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
>>>> 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
>>>>>followed by plain foo() in the code.
>>>>>Duncan Murdoch
>>>>>> But calling juliaUsing(), as it is now, takes care that if a
>>>>>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
>>>>>> If you call the code with attach() multiple times and do not
>>>>>you get your screen cluttered with
>>>>>> warnings "xxx is masked by xxx".
>>>>>> So I would say it would decrease user-friendliness to return an
>>>>>> 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.
>>>>>>>> | 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
>>>>>the law".
>>>>>>>> It might be worth mentioning that use of attach() is seen, to
>>>>>one poor
>>>>>>>> analogy, pretty much like use of global variables these days.
>>>>>>>> you could does not mean you should".
>>>>>>>> See e.g. one of the first google hits for 'r do not use attach'
>>>>>>> I don't have a strong opinion on this: the proposed use seems to
>>>>>>> worse than library() or require(). Those are fine for users to
>>>>>>> are discouraged in a package. If the attach() never happens
>>>>>>> explicit request from the user (and that's what it sounds like),
>>>>>>> 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
>>>>>>> using it as a prefix when they call the functions in it. So it's
>>>>>>> though this will destroy the utility of the package if Stefan
>>>>>>> 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
> --
> 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
> ______________________________________________
> 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

More information about the R-package-devel mailing list