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.kalib...@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@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to