Does it make sense to talk about the class of the output of substitute(...)? I'm puzzled by the following outputs: ee <- list( A = substitute( a <- 1 ), B = substitute({ a <- 1 }), C = substitute(( a <- 1 )), D = substitute( a == 1 ) )> t(sapply(ee, FUN=function(e) { c(typeof=typeof(e), mode=mode(e), class=class(e)) }))typeof mode class A "language" "call" "<-" B "language" "call" "{" C "language" "(" "(" D "language" "call" "call" That the mode in C is "(", is motivated in help("mode"): "that some calls have mode "(" which is S compatible." However, what's the explanation for the different classes? Is that intended or just "garbage" output? Thanks, Henrik
I've found 'while', 'for', 'if' and '=' appearing as the "class" of what would ostensibly be "call" objects, as well. (Came across this because I was using S3 dispatch to help do code-walking syntax transformations) I can't find where it is happening in R source, but it seems significant that they all are are things that deparse as other than function calls, and all are symbols that have SET_SPECIAL_SYMBOL marked in names.c --- although the converse does not hold for either statement. On Thu, Jan 2, 2014 at 5:16 PM, Henrik Bengtsson <hb at biostat.ucsf.edu> wrote:> Does it make sense to talk about the class of the output of > substitute(...)? I'm puzzled by the following outputs: > > ee <- list( > A = substitute( a <- 1 ), > B = substitute({ a <- 1 }), > C = substitute(( a <- 1 )), > D = substitute( a == 1 ) > ) > >> t(sapply(ee, FUN=function(e) { c(typeof=typeof(e), mode=mode(e), class=class(e)) })) > typeof mode class > A "language" "call" "<-" > B "language" "call" "{" > C "language" "(" "(" > D "language" "call" "call" > > That the mode in C is "(", is motivated in help("mode"): "that some > calls have mode "(" which is S compatible." However, what's the > explanation for the different classes? Is that intended or just > "garbage" output? > > Thanks, > > Henrik > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
On Thu, Jan 2, 2014 at 7:16 PM, Henrik Bengtsson <hb at biostat.ucsf.edu> wrote:> Does it make sense to talk about the class of the output of > substitute(...)? I'm puzzled by the following outputs: > > ee <- list( > A = substitute( a <- 1 ), > B = substitute({ a <- 1 }), > C = substitute(( a <- 1 )), > D = substitute( a == 1 ) > ) > >> t(sapply(ee, FUN=function(e) { c(typeof=typeof(e), mode=mode(e), class=class(e)) })) > typeof mode class > A "language" "call" "<-" > B "language" "call" "{" > C "language" "(" "(" > D "language" "call" "call" > > That the mode in C is "(", is motivated in help("mode"): "that some > calls have mode "(" which is S compatible." However, what's the > explanation for the different classes? Is that intended or just > "garbage" output??class has: "Many R objects have a class attribute, a character vector giving the names of the classes from which the object inherits. If the object does not have a class attribute, it has an implicit class, "matrix", "array" or the result of mode(x) (except that integer vectors have implicit class "integer"). (Functions oldClass and oldClass<- get and set the attribute, which can also be done directly.)" which suggests either a bug or some tweaks are needed to the documentation. Is there any point in ever using mode() except for S+ compatibility? It just adds some confusing aliases on top of typeof. Hadley -- http://had.co.nz/
Maybe Matching Threads
- Why is the diag function so slow (for extraction)?
- sum(..., na.rm=FALSE): Summing over NA_real_ values much more expensive than non-NAs for na.rm=FALSE? Hmm...
- Why is the diag function so slow (for extraction)?
- Long vectors: Missing values and R_xlen_t?
- How to test if an object/argument is "parse tree" - without evaluating it?