[R] Lexical scoping/calling stack issue: R fails to recognize an argument's default value

[Jeff Newmiller]

While you appear to have been thorough in providing access to your code, I don't think I will install a bunch of your dev code to debug it for you. The Posting Guide does say your example should be minimal, and IMO this doesn't fit that description. You should extract enough generic functions to replicate the structure of the call tree in a single short example.

I suppose there could be a bug in the parameter handling, but are you sure every calling point is including the "..." argument that should be?

My second blind point is that visibility of package variables does follow a complicated path, but there are good descriptions available, such as [1] or [2].

If you do think you have found a bug, the R Core team will want a minimal reproducible example, and you should read the Posting Guide on bug reporting to make sure your issue gets addressed.

[1] http://obeautifulcode.com/R/How-R-Searches-And-Finds-Stuff/
[2] http://adv-r.had.co.nz/Environments.html
---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
--------------------------------------------------------------------------- 
Sent from my phone. Please excuse my brevity.

On November 14, 2014 3:51:16 PM PST, Janko Thyson <janko.thyson at gmail.com> wrote:
>Dear list,
>
>I just encountered a behavior that I've never seen before:
>
>Is it possible, that certain argument names (lazy in my case) are
>special/reserved and thus would lead to unexpected behavior when a
>calling
>stack is involved that spreads across functions of three different
>packages: optionr::setAnywhereOptions() calls nestr::setNested() calls
>reactr::setShinyReactive()?
>
>Or is there something I'm generally missing with respect the
>combination of
>lexical scoping/the frame stack, S4 and default values of function
>arguments.
>
>Running the following code leads to a situation where the default value
>of
>`lazy` in `reactr::setShinyReactive()` is not properly recognized while
>others (e.g. `push`) are recognized just fine:
>
>require("devtools")
>devtools::install_github("Rappster/conditionr")
>devtools::install_github("Rappster/nestr")
>devtools::install_github("Rappster/optionr")
>require("optionr")
>
>container <- initializeOptionContainer(overwrite = TRUE)
>expect_true(setAnywhereOption(id = "x_1", value = TRUE, reactive =
>TRUE))
>expect_equal(getAnywhereOption(id = "x_1"), TRUE)
>expect_true(res <- setAnywhereOption(id = "x_2",
>  value = reactr::reactiveExpression(
>    !getAnywhereOption(id = "x_1")
>  ),
>  reactive = TRUE))
>
>The current version of `setShinyReactive()` contains a debugging
>section
>that prints these status messages (the actual code:
>https://github.com/Rappster/reactr/blob/bug-28/R/setShinyReactive.r#L196)
>
>DEBUG/push/before[1] FALSE
>DEBUG/lazy/before
>Error in print(lazy) : argument is missing, with no default
>DEBUG/is_lazy/before[1] FALSE
>DEBUG/lazy/after[1] FALSE
>
>It also contains my current workaround: also include an argument with
>name `is_lazy` (whose default)
>value is recognized again) and then run `lazy <- is_lazy`.
>
>You can also find this information in this Stackoverflow post:
>http://stackoverflow.com/questions/26940474/lexical-scoping-issue-r-fails-to-recognize-an-arguments-default-value
>
>Thanks a lot for everyone that can shed some light on this!
>
>
>Best regards,
>Janko
>
>	[[alternative HTML version deleted]]
>
>______________________________________________
>R-help at r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-help
>PLEASE do read the posting guide
>http://www.R-project.org/posting-guide.html
>and provide commented, minimal, self-contained, reproducible code.