4 Dec 2001Kestrel1 From Patterns to Programming Languages Matthias Felleisen Northeastern University

4 Dec 2001Kestrel2 Background and Experience Theory of PL Expressiveness PLT Scheme (IDE, tools, Scheme) –200 Kloc Scheme, 200Kloc C++ (inh) –400 downloads/day for last year 94/95: design patterns –use in implementation –implementing patterns in Scheme –“A Little Java, A Few Patterns” –papers on patterns for extensibility 96/97: Patterns in the IDE (ESOP)

4 Dec 2001Kestrel3 Patterns and Expressiveness

4 Dec 2001Kestrel4 Patterns (GoF) pattern name problem solution consequences adapter mismatch of interface create adapter class e.g., class adapters may introduce additional behavior

4 Dec 2001Kestrel5 Patterns (PL) name problem solution consequences store passing mismatch of interface: have FP, need state pass store as data structure; lookup & modify locations man. introduce additional behavior

4 Dec 2001Kestrel6 Patterns (PL: store passing) val xcount = ref 0; // xf : unit -> TypeG fun xf () = … xcount = !xcount + 1; G; would like, but don’t have val xcount = ref 0; // xf : int -> (TypeG, int) fun xf (xcount) = … let val xcount = !xcount + 1; in (G, xcount); here we go:

4 Dec 2001Kestrel7 Patterns (PL: store passing) fun f fun f-sps

4 Dec 2001Kestrel8 Patterns (PL) name problem solution consequences continuation passing mismatch of interface: have FP, need exceptions pass control as function introduce additional behavior

4 Dec 2001Kestrel9 Patterns (PL: continuation passing) // xf : unit -> TypeG fun xf () = … if cond then exit(10); else G; would like, but don’t have // xf : (GType -> FA) -> FA fun xf (roc) = … if cond then 10; else roc(G); here we go:

4 Dec 2001Kestrel10 Patterns (PL: continuation passing) fun f fun f-cps

4 Dec 2001Kestrel11 Patterns (PL) name problem solution consequences nested blocks lack blocks in FPL apply anonymous function physically separate variables from values

4 Dec 2001Kestrel12 Patterns (PL: nested blocks) (let ([x 10] [y 20]) … x … y … ) would like, but don’t have ((lambda (x y) … x … y … ) 10 20) here we go:

4 Dec 2001Kestrel13 Patterns (PL) name problem solution consequences for-loop lack for-loop in FPL use recursive function physically separate loop variable from initial value

4 Dec 2001Kestrel14 Patterns (PL: nested blocks) (for j = 10 to 20 (set! sum (+ sum j))) would like, but don’t have (for-each (lambda (j) (set! sum (+ sum j))) (build-list 10 (lambda (k) (+ k 10)))) here we go:

4 Dec 2001Kestrel15 Patterns from PL Landin: patterns are everywhere –some are local --> syntactic sugar –some are global --> essential constructs Strachey, Wadsworth: –denotational semantics & global patterns Felleisen (1988): –theory of expressiveness relative to a base language

4 Dec 2001Kestrel16 Patterns and Language Constructs

4 Dec 2001Kestrel17 Pattern Programming Programming with patterns is good. With Patterns, programmers can discuss lots of code with a few words. Patterns suggest invariants, helping reasoning about code.

4 Dec 2001Kestrel18 Pattern Programming Programming patterns explicitly is bad. Programmers may “lie” about patterns. Pattern maintenance may break logical invariants

4 Dec 2001Kestrel19 The Adapter Pattern: One More Time /* Adapter Pattern: object adapter GraphicalOutput adapts VendorGraphics to OutputRoutines */ interface OutputRoutines { … } class GraphicalOutput implements OutputRoutines { … } class VendorGraphics { … } two lines of comments explain 100 lines of code

4 Dec 2001Kestrel20 The Adapter Pattern: One More Time /* Adapter Pattern: object adapter GraphicalOutput adapts VendorGraphics to OutputRoutines */ class OutputRoutines { … } class GraphicalOutput extends OutputRoutines { … } class VendorGraphics { … } it’s no longer an adaptation -- it’s implementation inheritance

4 Dec 2001Kestrel21 Patterns as Comments When patterns are comments and informal language, nobody knows whether our claims are true. Somebody else may change the code or the comments. –Then they are out of sync. Are such patterns useful?

4 Dec 2001Kestrel22 Patterns as Language Constructs local patterns vs global patterns local patterns via syntactic extensions global patterns via aspects (?) –if aspects work, we can experiment with a pattern and see whether it is useful –if so, we should add them to the language.

4 Dec 2001Kestrel23 Scheme’s Macros: Principles Macros are transformations on the abstract syntax trees Macros respect the scoping (and other) information of the input ASTs. Macros respect the scoping information of their “host” module.

4 Dec 2001Kestrel24 Scheme’s Macros: Example (define-syntax let (syntax-rules () [(let ([ ]...)...) ((lambda (...)...)...)])) ;; use: (let ([x 10][y 20]) (printf "the variables are: ~s ~s ~n" x y) (+ x y))

4 Dec 2001Kestrel25 Local Patterns as Language Constructs (define-syntax-pattern Adapter [rewrite (_ adapts to as (fields...) (methods...))] [as (class implements (fields ( )...) (methods...))])

4 Dec 2001Kestrel26 Pattern Elaboration

4 Dec 2001Kestrel27 Patterns and Synthesized Information (Patterns and Proofs)

4 Dec 2001Kestrel28 Making Patterns as Constructs Work Programmers need to see information at the level at which they program. Information is: syntax error type error run-time exception reporting

4 Dec 2001Kestrel29 Information about Programs Matters MultiplicationExpression,struct MatrixDSL::int_number >,class MatrixICCL::Rect,struct MatrixDSL::int_number >>,class MatrixICCL::Dyn2DCContainer >,struct MatrixDSL::stat_val >,struct MatrixDSL::unspecified_DSL_feature>,struct MatrixDSL::dense,struct MatrixDSL::dyn >,struct MatrixDSL::speed,struct MatrixDSL::unspecified_DSL_feature,struct MatrixDSL::unspecified_DSL_feature,struct MatrixDSL::unspecified_DSL_feature,struct MatrixDSL::unspecified_DSL_feature>>::DSLConfig>::DSLConfig>>>>>,class MatrixICCL::Matrix,struct MatrixDSL::int_number >,class MatrixICCL::Rect,struct MatrixDSL::int_number >>,class MatrixICCL::Dyn2DCContainer >,struct MatrixDSL::stat_val >,struct MatrixDSL::unspecified_DSL_feature>,struct MatrixDSL::dense,struct Ma… (A + B) * C : misuse of variable produces:

4 Dec 2001Kestrel30 Patterns and Errors

4 Dec 2001Kestrel31 Pattern Macros: A Full Example expansion rules instance from GoF consistency error syntax check, scope check type check

4 Dec 2001Kestrel32 The Composite Pattern: New Syntax (COMPOSITE (ABSTRACT (FIELDS ( )...) (METHODS ( )) (ABSTRACT:METHODS...)) (CONCRETE (FIELDS ( )...) (METHODS ( )...)) (COMPOSITE:METHODS ( )...))

4 Dec 2001Kestrel33 (begin ;; --- ABSTRACT CLASS (define (class* object% () () (private ( )...) (public ( (lambda x (error ' "not implemented...))) ;; --- CONCRETE CLASSES (define (class* etc. ….. ………………………………………………))) The Composite Pattern: Elaboration

4 Dec 2001Kestrel34

4 Dec 2001Kestrel35

4 Dec 2001Kestrel36

4 Dec 2001Kestrel37

4 Dec 2001Kestrel38 Source Correlation to track source information through expansions to provide feedback in terms of original source

4 Dec 2001Kestrel39 Elaboration Tracking to keep track of history of macro transformations to help IDE untangle complex interactions between complex pattern embeddings

4 Dec 2001Kestrel40 Conclusion

4 Dec 2001Kestrel41 Summary patterns have a long history, pre-GoF patterns should be language constructs for the obvious reasons macros (and an expressive base language) can turn most patterns into language constructs

4 Dec 2001Kestrel42 Patterns via Macros abstract factory, factory, singleton, adapter, bridge, composite, decorator, façade, proxy, chain, command, interpreter, iterator, observer, state, strategy, visitor, template from local macros using a base language with higher-order functions and assignment

4 Dec 2001Kestrel43 Challenges global patterns a well-founded theory of patterns more experience with pattern in languages with explicit type declarations

4 Dec 2001Kestrel44 The End Shriram Krishnamurthi Daniel Friedman Cormac Flanagan and PLT