[Rd] attributes on symbols

[Lionel Henry]

It's probably better to make it a runtime error, but note that it's
not necessarily a bad idea to add attributes to singleton symbols.
Those are used in Emacs Lisp for a variety of purposes. They just need
strong conventions (part of that is that in Emacs many symbols are
prefixed with a "namespace" identifier).

https://www.gnu.org/software/emacs/manual/html_node/elisp/Symbol-Properties.html

Lionel


> On 11 août 2017, at 11:46, Tomas Kalibera <tomas.kalibera at gmail.com> wrote:
> 
> 
> Thanks for spotting this issue. The short answer is yes, adding attributes to a symbol is a bad idea and will be turned into a runtime error soon. Maintainers of packages that add attributes to symbols have been notified and some have already fixed their code.
> 
> At least in one case the package is not working properly, even in isolation, because of the global effect of adding an attribute to a symbol. Think about an expression "x - x", adding sign 1 to the "first x" and then sign -1 to the "second x" ends up with (both) "x" having sign "-1", because it is the same "x". The package would need something like a symbol, but passed by value (suggestions below).
> 
> By design in R symbols are represented by singleton objects registered in a global symbol table. Symbols are passed by reference and are fully represented by their name or pointer, so they can be quickly compared by pointer comparison and they can be used for bindings (naming variables, functions). Symbols thus cannot have attributes attached and must be treated as immutable. For this reason also attributes on symbols are not preserved on serialization (as Radford pointed out).
> 
> In some cases one needs to add an attribute to something similar to a symbol, but something passed by value. There are multiple ways to do it (credits for suggestions to Peter, Michael and others):
> 
> - wrap a symbol into an object passed by value, add an attribute to that object; such an object can be a list, an S3 or S4 object, an expression, etc; in "x - x", there will be two different wrappers of "x"
> 
> - encapsulate a symbol and needed meta-data (what would be in the attribute) together into an object passed by value, e.g. into S3/S4 object or a list; in "x - x", there will again be two different objects encapsulating "x"
> 
> - store the meta-data (what would be in the attribute) in a user environment created by new.env(); the meta-data could be conveniently looked up by the symbol and the environment can be hashed for fast lookup; from Peter:
>> attrib <- new.env()
>> attributes(sym) ----> attrib$sym
>> attr(sym, "foo") ----> attrib$sym[["foo"]]
> (the last suggestion will not work for the example "x-x", but may work for other where referential semantics is needed, but now in a well defined scope)
> 
> 
> Best,
> Tomas
> 
> 
> On 07/07/2017 03:06 PM, Torsten Hothorn wrote:
>> 
>> Here is a simpler example:
>> 
>>> ex <- as.name("a")
>>> attr(ex, "test") <- 1
>>> quote(a)
>> a
>> attr(,"test")
>> [1] 1
>> 
>> Torsten
>> 
>> On Thu, 6 Jul 2017, William Dunlap wrote:
>> 
>>> The multcomp package has code in multcomp:::expression2coef that attaches the 'coef' attribute to
>>> symbols.  Since there is only one symbol object in a session with a given name, this means that
>>> this attaching has a global effect.  Should this be quietly allowed or should there be a warning or
>>> an error?
>>> E.g.,
>>> 
>>> str(quote(Education))
>>> # symbol Education
>>> lmod <- stats::lm(Fertility ~ ., data = datasets::swiss)
>>> glmod <- multcomp::glht(lmod, c("Agriculture=0", "Education=0"))
>>> str(quote(Education))
>>> # symbol Education
>>> # - attr(*, "coef")= num 1
>>> 
>>> Bill Dunlap
>>> TIBCO Software
>>> wdunlap tibco.com
>>> 
>>> 
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel