[PPT] - Generic Programming, Partial Evaluation, and a New Programming PowerPoint Presentation

SLIDE 1

Generic Programming, Partial Evaluation, and a New Programming Paradigm

Aerospace Integration Science Center The Aerospace Corporation cal@aero.org

Aerospace Integration Science Center The Aerospace Corporation bellman@aero.org

SLIDE 2

Outline Introduction

. Goals and Progress, Examples

. Basic Approach, Futamura Projections, Performance Problem Posing Programming Paradigm Underlying Technology

. Coordination Manager, Study Manager, Meta-Recursion . Wrapping Knowledge Base Semantics

Applications

Conclusions

SLIDE 3

Generic Programming Goals and Progress A goal of programming since the beginning

Result would be

can be made explicit and deferred to pre-compile time

Generic Programming is about making programs more flexible

(e.g., programs, types, constructors, ...) Gradual improvements over the last 50 years: Machine language -> assemblers -> compilers -> interpreters Still looking for more effective techniques

SLIDE 4

Examples Algorithms are often written descriptively for explanation

Generic genetic programming algorithm: generate initial population loop until done compute offspring retain only the ones with best fitness Generic simulated annealing algorithm: set initial temperature and position loop until done generate potential new position check movement criterion reduce temperature Generic k-means clustering algorithm: generate initial cluster centers loop until done partition data into nearest-center clusters recompute cluster centers

SLIDE 5

Partial Evaluation: Basic Approach Simple idea

then you can specialize the program

Difficult to make it work

. Symbolic execution . Partly unrolling iterations and recursions . Program point specialization: Replicate parts of program with different specializations, Definition Creation, Folding, Memoization

Imagine a program ‘‘mix’’ that can do partial evaluation: for all programs p, and all inputs in1 and in2, [[mix] (p, in1)] in2 = [p] (in1, in2), so mix specializes p to the inputs in1 (such programs do exist for some languages) Partial evaluation provides an adaptation mechanism for generic programs

SLIDE 6

Futamura Projections We can get compilers and compiler generators out of partial evaluators (1970) Definition: An interpreter is a program interp for which: for all inputs in, and all source programs s, [interp] (s, in) = [s] in We claim that a kind of ‘‘compilation target’’ t for source program s can be computed: t = [mix] (interp, s), since for any input in,

= [s] in = [interp] (s, in) = [[mix] (interp, s)] in = [t] in, so mix specializes the interpreter via part of its input (the source program s) Now comp = [mix] (mix, interp) turns out to be a compiler for the language interpreted by interp: for any source program s, the compilation target t has t = [mix] (interp, s) = [[mix] (mix, interp) ] s = [comp] s

SLIDE 7

Futamura Projections (continued) So far, t = [mix] (interp, s) is a compiled form of s, comp = [mix] (mix, interp) is a compiler for the language interp interprets Finally, cogen = [mix] (mix, mix) is a compiler generator for the language interp is written in: for any interpreter interp, source program s, and input in, [s] in = [interp] (s, in) = [[mix] (interp, s)] in = [[[mix] (mix, interp)] s ] in = [[[[mix] (mix, mix)] interp] s] in, = [[[cogen] interp] s] in so [cogen] interp = [comp] is a compiler for the language of s

SLIDE 8

Performance of Partial Evaluation The use of these formal projections looks nice

Two ways to produce output with these notions:

= [interp] (s, in) = [s] in t = [mix] (interp, s) = [comp] s comp = [mix] (mix, interp) = [cogen] interp cogen = [mix] (mix, mix) = [cogen] mix The second way is often something like 10 times faster The first way is usually much easier to write (once the program mix is written) We want to use this fact to write faster programs more easily

SLIDE 9

Problem Posing Programming Paradigm All programming languages have a notion of information service

We connect them now by using the same names ‘‘Problem Posing’’ is a new declarative programming style

Programs interpreted in this style ‘‘pose problems’’; they do not

(these are information service requests) Program fragments are ‘‘resources’’ that can be ‘‘applied’’ to problems; they are not

(these are information service providers)

SLIDE 10

Problem Posing Programming Paradigm (continued) The Problem Posing interpretation separates the requests from the providers

We call the service requests ‘‘posed problems’’ We call the service providers ‘‘resources’’ We can connect them through knowledge bases (or other means)

. From the problem specification in its context . To the computational resources that will organize the solution Any programming language can be interpreted in this new way (well, almost any) Problem Posing changes the semantics of programming languages, not the syntax

. Instead of an organized collection of solutions without problems

. Because the problems at all levels of detail remain in it

SLIDE 11

Examples C

Lisp

that poses other problems

Smalltalk

(including which object receives the message), to other posed problems

Prolog

to other posed problems

SLIDE 12

Wrapping: Knowledge Based Integration Infrastructure Problem Posing is particularly effective in combination with ‘‘wrappings’’ Computationally reflective knowledge-based integration infrastructure

AND

Wrapping has four main features

. Tools, components, interfaces, even architectures

. A resource is ‘‘applied’’ to a ‘‘posed problem’’ . Separate problem to be studied from the resources that might study it

. Not just ‘‘how’’, but ‘‘when’’, ‘‘why’’ and ‘‘whether’’ . Wrapping Knowledge Bases (WKBs) contain all the wrappings

. Use implicit invocation, both context and problem dependent . Knowledge-Based Polymorphism . These wrapping processes are also resources; they are also wrapped (Computational Reflection) . Coordination Manager (CM) and Study Manager (SM) are two PMs

SLIDE 13

Coordination Manager (CM) The CM is a simple analog of ‘‘read-eval-print’’ in LISP Find Context loop Pose Problem Study Problem Present Results The CM is a kind of ‘‘heartbeat’’ for a wrapping-based system CM steps

(e.g., menu of choices, interpretation of invocation parameters, etc.)

(e.g., by parsing)

Context is very important in this approach

. Semantics _is_ interpretation of syntax

. ‘‘Sanity Checks’’ are constraints determined by context

SLIDE 14

Study Manager (SM) The SM is our central approach to problem study

The SM is a (VERY) simple planning algorithm: Interpret Problem: Match Resources Resolve Resources Select Resource Adapt Resource Advise Poser Apply Resources Assess Result SM steps

(it uses a quick and simple filter through the WKBs)

(it negotiates between the resource and the posed problem)

SLIDE 15

Meta-Recursion The SM (by itself) is a simple-minded planner that considers only one step at a time Recursion in the meta-direction

. Independence from wrapping syntax and semantics The system therefore has ‘‘knowledge’’ of its own resources

Bottoming out of the recursion

. No simplest form for adaptation, because that is hard Not necessarily immediate execution of resource functions

. Or analyzing it and placing the result in a structure (e.g., V&V)

We make essential use of this reflection in our partial evaluations

SLIDE 16

Wrapping Knowledge Base Semantics Wrapping Knowledge Base (WKB) information

. Assumptions, limitations, applicability, scope, styles of use

. There are some common entries because the WKB supports the SM steps For each resource, a sequence of entries

. Relevant specializations, methods of application Use of wrappings (Intelligent User Support Functions)

. The key to Use

. The key to ReUse (hard!)

. The key to Understanding (harder!)

SLIDE 17

Wrex (Wrapping Expression Notation) Syntax reflects the central role of the posed problem in Problem Posing

Syntax definition for posed problem (general): <posed problem> ::= <prob> ‘[’ <data> ‘]’ [‘in’ <context>] [‘by’ <study manager>] Default context (when ‘in’ phrase is omitted) is current context at problem pose time Study Manager (when ‘by’ clause is present) is the one to use to _find_ an SM

Syntax items

. List: multiple items, separated by commas, delimited by ‘[]’ . Set: multiple items, separated by commas, delimited by ‘{}’ . Group: multiple items, separated by commas, delimited by ‘()’ (Groups not in groups can omit parentheses)

. E.g., ‘find [ ... ] in [ ... ] using [ ... ]’

. The simple posed problem is a group whose last element is a list

SLIDE 18

Example of wrex Syntax: Coordination Manager define CM [ <user> ]: [ Find context [ <user> ], for ever : [ <problem> = Pose problem [ <user> ], <result> = Study problem [ <user>, <problem>, <context> ], Present results [ <user>, <result> ] ] ], Discussion of syntax features

. ‘define’ ‘CM’ ‘[ ... ]’ ‘:’ ‘[ ... ]’

. So is ‘define’ ... ‘:’ ‘[ ... ]’

. It is also a posed problem with problem name ‘=’

. So is ‘=’

SLIDE 19

Example of wrex Syntax: Study Manager define SM-simple [ <poser>, <prob>, <data>, <context> ]: [ <candidates> = Match resources [ <prob>, <data>, <context> ], if (<candidates> == empty): then return FAIL_NO_CANDS, <candidate applications> = Resolve resources [ <candidates>, <prob>, <data>, <context> ], if (<candidate applications> == empty): then return FAIL_NO_APPLS, <selection> = Select resource [ <candidate applications> ], <resource application> = Adapt resource [ <selection>, <prob>, <data>, <context> ], <resp> = Advise poser [ <poser>, <resource application>, <prob>, <data>, <context> ], if (not <resp>): then return FAIL_NO_APPLS, <result> = Apply resource [ <poser>, <resource application>, <context> ], <success flag> = Assess results [ <result>, <prob>, <data>, <context> ], return <result> ],

SLIDE 20

Applications Coordination Languages in distributed systems

. It is independent of particular language assumptions . We need an interpreter within each program in the system (this is not too hard)

. The coordination language can remain as the components change, also Reuse Without Modification

. They always know the difference between definition and use of symbols

. For example, intercept the function calls from the called functions

. Instrumentation . Monitoring . Different functions under different conditions . Completely new functions for previously difficult situations

. Old code is kept only as long as it is still useful

SLIDE 21

Decision Times and Performance Decision times

Too many decisions at run-time

We can use our knowledge of the execution environment with partial evaluation

. If we know that a posed problem is only addressed by one resource, we can avoid the full search and the SM recursion Partial evaluation of wrex

. Program and input data, as usual . Context data . Collection of available resources

SLIDE 22

Conclusions and other Claims Generic Programming

Partial Evaluation

. We don’t know how fast it will be, but we’re very hopeful . We want programs that are BOTH easier to write AND faster to run

Problem Posing

. Reuse without modification

. Coordination language . Needs language to accept information from outside (hard for some) None of this solves the hard problems in any particular domain (they are still hard)