[R] Does R have a "const object"?

Gabor Grothendieck ggrothendieck at gmail.com
Wed Mar 16 22:42:27 CET 2011

On Wed, Mar 16, 2011 at 1:12 PM,  <luke-tierney at uiowa.edu> wrote:
> On Wed, 16 Mar 2011, Gabor Grothendieck wrote:
>> On Wed, Mar 16, 2011 at 12:16 PM,  <luke-tierney at uiowa.edu> wrote:
>>> On Wed, 16 Mar 2011, Gabor Grothendieck wrote:
>>>> On Wed, Mar 16, 2011 at 11:49 AM,  <luke-tierney at uiowa.edu> wrote:
>>>>> Just as a heads-up: it is likely that unlocking the bindings in base
>>>>> for pi, T, F, probably all BULTIN and SPECIAL functions, and possibly
>>>>> more, will start signaling warnings in the near future.  Doing this
>>>>> may be useful at times for debugging but it can mess up assumptions
>>>>> others make about how things in base work and so reduce code
>>>>> reliability.
>>>> That seems ok for pi, T and F but if its extended to everything in
>>>> base then I would hope there is a nowarn= argument or other easy way
>>>> to avoid the warning message.
>>> That would defeat the purpose.  Unlocking things in base may be useful
>>> for experimenting or debugging but it is not a good idea otherwise.
>>> [? assignInNamespace could be more explicit on htis and will be soon.]
>>> There is a reason we lock bindings in the first place, and that is so
>>> one can assume that these bindings have certain values and certain
>>> properties and one can write reliable programs against these
>>> assumptions.
>> Its useful for being able to set defaults for arguments that do not
>> have defaults.  That cannot break existing programs.
> Until the next program decides do co change those defaults and either
> can't or does and you end up with incompatible assumptions.  It also
> make the code with the added defaults inconsistent with the
> documentation though, which is not a good idea.  It may seem
> convenient but it isn't a good idea in production code that is
> intended to play well with other production code.
>> Note that if this feature is implemented in a heavy handed manner it
>> could cause havoc as at least one package that is depended upon by
>> literally dozens of other packages (and possibly hundreds if one takes
>> into account dependencies of dependencies) cannot function.
> The reason I sent my initial message is so those who do this sort of
> thing can start thinking about other approaches.  I do not expect to
> need this change for closures any time soon, but will need it for
> constants and primitives.  It may be useful for some closures as well,
> so that change may come farther down the line.

If the core group is willing to fix certain design errors in R that
make this necessary I would not be so concerned but to not address
them and also remove the facility that lets the user implement a
workaround is really intolerable.

Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

More information about the R-help mailing list