I am trying to manipulate some parsed R code and have run into difficulty with the = operator. As this snippet shows, I can get an object that says its type is "language", but it then returns false on the "is" test that R uses when assigning a value to a slot of an S4 class.
Here is some sample code:
parsed <- parse(text = "cylinders = c(4, 6, 8)")
print (typeof(parsed)) # Prints "expression"
langObj <- parsed[[1]]
print (typeof(langObj)) # Prints "language"
print (is(langObj, "language")) # Prints FALSE
setClass("Foo",
slots = list(
s1 = "language")
)
setMethod ("initialize",
"Foo",
function(.Object, obj){
.Object@s1 <- obj
return (.Object)
}
)
new (Class = "Foo", langObj)
This last line produces the error:
Error in (function (cl, name, valueClass) :
assignment of an object of class “=” is not valid for @‘s1’ in an object of class “Foo”; is(value, "language") is not TRUE
Note that if the <- operator is used in place of =, the code works as expected.
What is the difference between "typeof" and "is"? Why does the = operator not yield a "language" value, while <- does?
The parser is what converts the textual representation of R code into an internal form which may then be passed to the R evaluator which causes the specified instructions to be carried out. The internal form is itself an R object and can be saved and otherwise manipulated within the R system.
Using lapply() or pblapply() along with fromJSON , R will parse each of the JSON objects to create all. cities . You nest the result in unlist so the output is a simple string vector. With this code, you have all prefill cities organized into a vector that you can use to construct the actual webpages containing data.
The result of the %% operator is the REMAINDER of a division, Eg. 75%%4 = 3. I noticed if the dividend is lower than the divisor, then R returns the same dividend value.
%>% is called the forward pipe operator in R. It provides a mechanism for chaining commands with a new forward-pipe operator, %>%. This operator will forward a value, or the result of an expression, into the next function call/expression. It is defined by the package magrittr (CRAN) and is heavily used by dplyr (CRAN).
You need to understand that typeof
returns a fairly low level characterization and that is( ... , "language")
tests a somewhat higher level of abstraction. There is not much use for typeof
. It's generally more useful to ask for the class of an object:
> class(parsed)
[1] "expression"
> class(parsed[[1]])
[1] "="
This second one might seem a bit odd, and I would have thought it to be eitehr a call
or and Ops
result, but if you look at:
parsed[[1]]
#cylinders = c(4, 6, 8)
You see that the call object is represent internally, i.e. the parse-tree, as:
`=`( cylinders, c(4, 6, 8) )
... noting that:
parsed[[1]][[1]]
`=` # note the backticks signifying a function, a language object
... and that this is really a call-object:
is.call( parsed[[1]] )
#[1] TRUE
See ?parse
where it is explained that the function returns an unevaluated call-object. I'm more of an S3 guy so trying to explain what's going wrong with your S4 stuff is above my pay grade. Notice that the error message from your failed S4 efforts referred to a mismatch of 'class' rather than 'typeof'
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With