Repository navigation
Need to remove nimble namespace uses #60
Description
Now that nimble2 is well into development, it would be good to remove all calls to nimble from nimbleModel. It creates a development pain because nimble2 naturally has many of the same names as nimble, and having nimble::foo forces loading of its namespace, and that creates name conflicts. In some stew of devtools::load_all and the RStudio project system, this can also result in automatically loading the namespace using cached information even on restarts, so it takes some forceful annoying actions to clear it.
Activity
perrydv commentedon Oct 13, 2026
@paciorek I am looking at this and want to sketch out questions that come up and propose a plan.
The questions are about potentially circular dependencies between
nimble2andnimbleModel. This could happen in two ways:nf_changeNimKeywords: This is currently innimble2(a direct copy fromnimble). There it is used on all DSL code. But it should also be used on all model declarations, andnimbleModelcurrently callsnimble::nf_changeNimKeywordsto do that. If we make thatnimble2::nf_changeNimKeywords, thennimbleModelwill depend onnimble2and vice-versa.calc_dmnormAltParamsandcalc_dwishAltParams: These are both written asnimble::nimbleFunction. If we change it tonimble2::nimbleFunction, we'll again have circular package dependencies.Here are my proposed resolutions:
nf_changeNimKeywords(perhaps renamed) tonimbleModel. Let it take the list of keyword changes as an input, not use it as a global. Split the current list ofnimKeyWordsinto two parts, one to go intonimbleModeland another to stay innimble2. Most of the keyword replacements are in the former category: anything that is allowed in model code. Thenimble2can call fornimbleModelreplacements and its ownnimble2replacements on all DSL code. This change would also require the Rexecution versions of functions (e.g.nimNumeric) to be moved fromnimble2tonimbleModel. In some ways this seems a little clunky but it is the easy and obvious solution and would let nimbleModels be fully operational as uncompiled objects within thenimbleModelpackage.calc_dmnormAltParamsandcalc_dwishAltParamsas plainnFunctions, so they rely only onnCompiler, notnimble2. There may be some tweaks needed innimble2to go with this, but it should be feasible.Let me know what you think, especially of (1).
paciorek commentedon Oct 14, 2026
Direct reactions:
nf_changeNimKeywordsinnimbleModel(but see points at bottom). I am wondering if we should change it tochangeModelKeywordsor some such (possibly still using a global). Then innimble2I think we might want to have a separate functionchangeNimKeywords(and accept some code duplication) that does the DSL code changes. I'm not sure we wantnimble2to callnimbleModelfor that aspect that doesn't relate to models. RegardingnimNumericthat seems a bit awkward to me too, but I guess for anything that can be used in model code it needs to be defined innimbleModel. I am wondering if we want a second definition in some cases for operators that are available in models and in the DSL. But maybe we just live with getting them fromnimbleModeleven though they are usable in the DSL too.nFunctions, not just for the reasons you state but because I think we want to generally be using native nCompiler functionality now rather than going through the nimble2 bridge.While we're talking, some bigger picture thoughts that might change our thinking:
nimbleModelthough I don't have a good idea of what it should be.) Sonf_changeNimKeywordsandnimNumericwould be innimble2. It is feeling like the fact that we are in this circularity means our current division of content into packages may need rethinking.paciorek commentedon Oct 14, 2026
I'll also say that we might just want to have you disentangle things from nimble itself in the way you are suggesting and then we revisit packaging in a bit but not try to do it right now.
paciorek commentedon Oct 14, 2026
Also a note that I'd like for us to merge in PR #62 before you start making changes discussed here. It's a bit of stuff I mostly did back in late July.
It's related in that it uses
nRep,nC,nSeqbehind the scenes if a user hasrep,c,seqin model code. Some of it might need some tweaking as you/we work through the packaging stuff, but I'd prefer you/we start with what I had done in that PR.perrydv commentedon Oct 14, 2026
I agree it would be good to discuss and make a clear delineation between what lives in
nimbleModelvsnimble2. I have some ideas.For the moment, I'd like to take a practical path to get to where we can work on both packages, and that is somewhat blocked (a pain) by
nimbleModelloadingnimble's namespace.We can wait for your #62, but that has test failures from
calc_dmnormAltParams, which uses oldnimble, which is part of what I want to clean up. I might be able to work on that orthogonally. I'll see.perrydv commentedon Oct 14, 2026
A use of
nimblethat would be best for you to look at is intest-setupMargNodes, where we havenimble:::testConditionallyIndependentSets. Is that something you can port to nimbleModel?paciorek commentedon Oct 14, 2026
Ok, let me get out of my PR #62 rabbithole. I'll deal with that content after we deal with this issue. So please proceed based on current
master.paciorek commentedon Oct 14, 2026
Yes, I can port
testCondIndSets.