attributes on symbols

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

attributes on symbols

R devel mailing list
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

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: attributes on symbols

Torsten Hothorn-5

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
>
>
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: attributes on symbols

Radford Neal
In reply to this post by R devel mailing list
Attributes on symbols seem like a bad idea to me.  An additional
obscure part of the global state seems undesirable.  I can't see how
any use of them would be preferrable to storing an environment in some
global variable, in which the same information could be recorded.

Note that the attributes on symbols are not saved when the workspace
is saved with q("yes").

   Radford Neal

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: attributes on symbols

Tomas Kalibera
In reply to this post by Torsten Hothorn-5

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
>>
>>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
>>>
>>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel