R help - Nov 2014 - Lexical scoping/calling stack issue: R fails to recognize an argument's default value

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]]

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.