1. Yet another object
system for R
Hadley Wickham
Rice University
Friday, 31 July 2009

2. Does R need another
object system?
Friday, 31 July 2009

3. Are S3 and S4
enough?
Friday, 31 July 2009

4. “Because it’s there”
—George Mallory
CC BY: http://www.flickr.com/photos/mckaysavage/497617014
Friday, 31 July 2009

5. 1. Paradigms of programming
2. Existing systems in R
3. Prototype based programming
4. Examples
5. Scoping
6. Uses
Friday, 31 July 2009

6. Descriptive
declarative
programming
XML,
Data structures only S!expression
Turing complete + procedure
+ cell (state)
First!order Imperative
Observable functional programming
nondeterminism? Yes No programming Guarded
command + nondet. choice Pascal, C
+ closure programming Imperative
Functional Dijkstra’s GCL search
programming + search
programming
+ unification Scheme, ML + name SNOBOL, Icon, Prolog
(equality) (unforgeable constant)
Deterministic + continuation + cell
ADT + cell ADT + port
logic programming Continuation functional imperative (state) + closure
programming (channel)
programming programming Sequential
+ search Scheme, ML Event!loop object!oriented
Haskell, ML, E CLU, OCaml, Oz programming
Relational & logic + by!need + thread programming
programming synchron. + single assign. + nondeterministic + port E in one vat Stateful
Prolog, SQL Lazy Monotonic choice (channel) + thread functional
embeddings functional dataflow Nonmonotonic Multi!agent programming
Multi!agent
+ solver programming programming dataflow dataflow programming Java, OCam
Constraint (logic) Haskell Declarative programming programming + thread
Message!passing
programming concurrent Concurrent logic Oz, Alice, AKL concurrent Concurrent
CLP, ILOG Solver programming programming programming object!oriented
+ thread Pipes, MapReduce Oz, Alice, Curry, Excel, Erlang, AKL programming
+ thread + by!need AKL, FGHC, FCP Shared!state
Concurrent + single assignment synchronization + local cell
constraint + synch. on partial termination concurrent
programming Lazy Functional reactive Active object programming
dataflow programming (FRP) programming Smalltalk,
LIFE, AKL programming
Continuous synchronous Object!capability Java, Alice
+ by!need synchronization Lazy programming
programming + log
Lazy concurrent declarative
constraint concurrent FrTime, Yampa CSP, Occam, Software
programming programming + clocked computation E, Oz, Alice, transactional
publish/subscribe, memory (STM)
Oz, Alice, Curry Oz, Alice, Curry Discrete synchronous tuple space (Linda)
programming SQL embeddings
Logic and Esterel, Lustre, Signal Dataflow and
constraints Functional message passing Message passing Shared state
Nondet. state
Unnamed state (seq. or conc.) Named state
Less More
Friday, 31 July 2009 Expressiveness of state

7. Programming Paradigms for Dummies:
What Every Programmer Should Know.
Peter Van Roy.
http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf
P. van Roy and S. Haridi. Concepts,
Techniques and Models of Computer
Programming. The MIT Press, 2004.
Friday, 31 July 2009

8. S3 / S4 Alternative
Immutable Mutable
(pass-by-value) (pass-by-reference)
Generic functions Message passing
(function based OO) (class based OO)
Friday, 31 July 2009

9. Mutable Immutable
Required by many of Hard to derive
most efficient algorithms computational complexity
Simplifies dependence
Must “thread” state
between components
Concurrency hard Concurrency easy
Compilers can make
Hard to reason about
very efficient
Friday, 31 July 2009

10. Aside: memory efficiency
“A persistent data structure is a data structure
which always preserves the previous version of
itself when it is modified.”
“While persistence can be achieved by simple
copying, this is inefficient in time and space,
because most operations make only small changes
to a data structure. A better method is to exploit
the similarity between the new and old versions to
share structure between them, such as using the
same subtree in a number of tree structures.”
http://en.wikipedia.org/wiki/Persistent_data_structure
Friday, 31 July 2009

11. Existing systems
S3/S4: immutable + generic functions
R.oo : mutable + generic functions
OOP: mutable + message passing
Proto: mutable + message passing
YAROS: mutable + message passing
Friday, 31 July 2009

12. Prototype based
programming
Generalisation of class-based oo (like
Java) that removes the distinction
between classes and instances.
Single dispatch, but often implement
multiple (& dynamic) inheritance
Notable languages: Javascript, Io
Friday, 31 July 2009

13. Counter <- Object$clone()$do({
init <- function() self$counter <- 0
count <- function() {
self$counter <- self$counter + 1
self$counter
}
})
counter_a <- Counter$clone()
counter_b <- Counter$clone()
counter_a$count()
counter_a$count()
counter_b$count()
Friday, 31 July 2009

14. Account <- Object$clone()$do({
balance <- 0.0
deposit <- function(v) self$balance <- self$balance + v
withdraw <- function(v) self$balance <- self$balance - v
show <- function() cat("Account balance: $", self$balance, "n")
init <- function() self$balance <- 0
})
Account$show()
cat("Depositing $10n")
Account$deposit(10.0)
Account$show()
Savings <- Account$clone()$do({
interest <- 0.05
withdraw <- NULL
})
Savings$show()
Friday, 31 July 2009

15. Observable <- Object$clone()$do({
listeners <- list()
add_listener <- function(f) {
self$listeners <- c(self$listeners, f)
}
signal <- function(...) {
for(l in self$listeners) l(...)
}
init <- function() {
self$listeners <- list()
}
})
counter_a$append_proto(Observable$clone())
Friday, 31 July 2009

16. Advantages
Clean separation of object methods and
base functions.
No extra function parameters.
Rich behaviour, including introspection,
based on io.
Mutable, multiple inheritance
(depth-first search of inheritance graph).
Friday, 31 July 2009

17. Scoping
self$method() needs to have object
scoping, not lexical scoping.
That is, rather than looking up based on
environment at time function was defined,
look it up based on current object.
Friday, 31 July 2009

18. "$.io" <- function(x, i, ...) {
res <- core(x)$get_local_slot(i)
object_scope(res, x)
}
object_scope <- function(res, self) {
# Add environment to top of stack that contains
# the self object
if (is.function(res)) {
env <- new.env()
env$self <- self
parent.env(env) <- environment(res)
environment(res) <- env
}
res
}
Friday, 31 July 2009

19. Uses
Can simplify code which requires
coordinating data from multiple locations:
scale code in ggplot2
Complex simulations: e.g. card counting
in black jack
When there really is one true underlying
object: GUIs and interactive graphics
Friday, 31 July 2009

20. Conclusions
S3/S4 don’t fulfil every need, and it’s fun to
experiment with alternative paradigms.
Prototype-based OO is an interesting idea
that the distinction between inheritance
and instantiation.
We can actually implement it in R, with
different scoping rules. Has been a great
learning experience.
Friday, 31 July 2009