1 / 20

Java Mint: A Call for Questions

Java Mint: A Call for Questions. Walid Taha Rice University. Please open your mail client. and start writing To: taha@rice.edu Subject: Your Java Mint Talk ... and send comments during the talk. Multi-stage Programming. In a nutshell: We love abstractions

harsha
Download Presentation

Java Mint: A Call for Questions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Java Mint:A Call for Questions Walid Taha Rice University

  2. Please open your mail client and start writing To: taha@rice.edu Subject: Your Java Mint Talk ... and send comments during the talk

  3. Multi-stage Programming In a nutshell: • We love abstractions • We don’t like to pay for them • Multi-stage programming = abstractions - runtime cost

  4. Java Mint Multi-stage programming worked nicely in the purely functional setting Can we do the same in bigger languages?

  5. This Talk A call for discussion. The plan: • Defining “abstractions” • The functional theory of MSP (‘97-‘09) • Why this theory matters • Building the new theory

  6. “Abstractions”

  7. Abstraction Mechanisms • A way of writing code so that is • is parameterized, and • can be instantiated by providing parameters • Note: no loss of information We call them “abstractions” for short

  8. Purely Functional Abstractions • Primitive functions • Lambda abstractions • Module definitions, and functors • Records • Variants (using “The Trick”) MSP can guarantee the elimination of all of these overheads MSP types are well matched to a structural type system

  9. Object-Oriented Abstractions These are the kinds of things we would like to deal with in the OO setting: • Objects (as records/fields) • Objects (as methods) • Object creation • Mixins (?) • Aspects (already staged?) • Design Patterns (?? Require formalization)

  10. The Theory of Functional MSP

  11. Why bother with “the theory”? There is a huge body of results on various technical aspects of functional MSP What we don’t talk about much in technical papers is how do we put all of these results together? We need to revisit this “big picture” at this juncture

  12. The Functional Theory of MSP • In (Static Types and Scoping) We Trust • Staging = modifying evaluation order • Future stage values are extensional • Staging annotations are lightweight (3+1) • Code type constructor is simple, orthogonal • Multi-stage Programming • Naive: Just annotate • Realistic: Convert to CPS, and annotate

  13. The Functional Theory of MSP • Staging affects only termination • Programmers know how to ensure correct termination behavior • Statically typed program generation = staging + expressive static types • Expressive static types = CiC/Coq

  14. What Does FMSP Matter? • eval: exp * (id -> val) -> val • seval: exp * (id -> <val>) -> <val> • typecheck: exp -> (!t . texp t) option • teval: texp t * (i:id -> T(i)) -> t • steval: texp t * (i:id -> <T(i)) -> <t> • bottom line: steval = 10 * seval = 40 * eval

  15. Building the New Theory

  16. Concrete Questions • Can we achieve safe imperative MSP? • Can we keep notation lightweight? • Sam: Can we get away without HOFs? • Killer app: FOP, Yannis’s examples? • Can we avoid altering effects? • Does Java need more expressive static types? If so, how can we add them? • Can we preserve extensionality? • Can we improve break even points? • Tim, Jacques: What will the PG programming style be, and how do you teach it? • Ras: Do programmers what to treat as early and what to treat as late?

  17. Bigger Questions Can program generation gain broad, respectable acceptance? • Net Gain: Can we show that program generation introduces less problems than it solves? • Vanishing: Can we show that using program generation is “just programming”? • Doug: Certifying boards need to recognize things other than testing for certification (such as program generation). Can we generate certificates with programs? (Is this already being done in the ORF Tom Maibaum, FAA speaker at PCC)

  18. Call To Action Mint needs you! • Designing a Meta-Java is harder • Java is more complicated • We want to take harder problems • Need group involvement in • Design, implementation, testing, evaluation • Get on the list (tell me at top of your email)

  19. Final Words • OOMSP is an enormous challenge • We should take on hard challenges • We can meet hard challenges • Coming up with environment classifiers took 8 years

  20. Acknowledgment Thanks to the participants of the WG 2.11 for valuable discussions, and for Jacques and William for feedback they email after the talk.

More Related