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

From: Gabor Grothendieck <>
Date: Wed, 16 Mar 2011 17:42:27 -0400

On Wed, Mar 16, 2011 at 1:12 PM, <> wrote:
> On Wed, 16 Mar 2011, Gabor Grothendieck wrote:
>> On Wed, Mar 16, 2011 at 12:16 PM,  <> wrote:
>>> On Wed, 16 Mar 2011, Gabor Grothendieck wrote:
>>>> On Wed, Mar 16, 2011 at 11:49 AM,  <> 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

______________________________________________ mailing list
PLEASE do read the posting guide
and provide commented, minimal, self-contained, reproducible code.
Received on Wed 16 Mar 2011 - 21:48:45 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Wed 16 Mar 2011 - 21:50:21 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive