Yet another object system for R

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Favorites, Groups & Events

    Yet another object system for R - Presentation Transcript

    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
    SlideShare Zeitgeist 2009

    + Hadley WickhamHadley Wickham Nominate

    custom

    425 views, 0 favs, 1 embeds more stats

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 425
      • 135 on SlideShare
      • 290 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 3
    Most viewed embeds
    • 290 views on http://blog.had.co.nz

    more

    All embeds
    • 290 views on http://blog.had.co.nz

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories