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

2. Please open your mail client and start writing To: taha@rice.edutaha@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 -> )-> typecheck:exp -> (!t. texp t) option teval:texp t * (i:id -> T(i)) -> t steval:texp t * (i:id -> 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.