Next Generation Software Systems and Programming Languages Research

1
Next Generation Software Systems and Programming
Languages Research

• Matthias Felleisen

2
Our Experience

• PLT has built a bunch of software, including PDE,
  Web server, IMAP clients, and many more.
• These products share a number of characteristics
  with other modern software products.
• What does our experience suggest for PL research?

3
My Thesis, My Goal

• Software systems have become extensible
  collections of components.
• What does this mean for programming languages
  linguistics, pragmatics, virtual
  machines/compilers, and run-time environments?

4
Outline

• Two Examples DrScheme, Web Server
• Language Support for COP
• Virtual Machine Support
• Contracts for Components
• Summary, Advice

5
Disclaimer

• PLTs experience
• My thesis and trajectory
• these are not universal concerns

6
Examples Extensible Systems
7
Two Examples

• DrScheme a modern, pedagogic programming
  environment
• The PLT Web Server an experiment in serving
  dynamic Web content

8
DrScheme

• What does it take to build a PDE from scratch?
• How about extensions?

9
DrScheme
scope-sensitive syntax checker
syntax-sensitive editor
static debugger
algebraic stepper
interactive evaluator
10
Thank You to a Fantastic Team
11
DrScheme
model
view
Editor
GUI
Read-Eval-Print-Loop
mutual references
12
DrScheme Plugging in Tools
Syntax Checker
Editor
Tools -- plug-ins
Read-Eval-Print-Loop
Algebraic Stepper
13
DrScheme Plugging in Student Programs
Syntax Checker
Editor
Tools -- plug-ins
Read-Eval-Print-Loop
Algebraic Stepper
Student Programs
14
DrScheme The Big Picture
a single execution environment the VM
Editor
Read-Eval-Print-Loop
15
DrScheme

• powerful plug-ins that interact with editor and
  read-eval-print loop
• student programs become dynamically plugged in
  components
• easy communication among all components

16
A Web Server From Components

• What does it take to build a Web server?
• What about dynamic content?

17
A Web Server From Components
A server is basically a read-eval-print loop.
Upon a TCP connect read a request GET
/uniquelylara/paintings/index.html HTTP/1.0
headers interpret the request, the path,
and the headers dispatch on file path,
check for defaults, print the file send
the requested file back via a TCP write
18
A Web Server From Components
pattern matching
TCP connections
URL parsing
HTML
These components are good old libraries.
Dispatcher
REPL aka Web Server
19
A Web Server From Components
pattern matching
TCP connections
URL parsing
HTML
Dis remote
Dis local
Dis dynamic
REPL aka Web Server
code duplication
20
A Web Server From Components
pattern matching
TCP connections
URL parsing
HTML
local
Dispatch
Dispatch
Dispatch
remote
REPL aka Web Server
dynam
these components are parameterized and
instantiated
21
Web Server Dynamic Content

• dynamic content generation is becoming more and
  more important
• dynamic content generation is inefficient and
  slow
• dynamic content generation is difficult to manage

22
Web Server Plug-in Scripts
Dispatcher
Scripts
Server Loop
23
Web Server Scripts as Components
dynamically linked
Dispatcher
Server Loop
exchange of values not bit streams
24
Web Server Scripts as Components
store script as first-class value
Dispatcher
Server Loop
25
Web Server Scripts as Components
link in once
Dispatcher
Server Loop
26
Web Server Scripts as Components
link in once, link in twice
Dispatcher
Server Loop
27
Web Server Scripts as Components
Dispatcher
Server Loop
make the internals of the server available
stack, environment, store
28
A Web Server From Components

• Our Web servers performance for dynamic content
  generation is four times better than that of
  Apache/Perl and 20 to 40 than mod-Perl.
• It is the only Web server whose scripts are
  automatically safe for back buttons and cloning
  control state.

29
Other Examples

• Linux
• kernel modules
• applications
• Web browsers
• plug-ins
• applets
• Multimedia players
• drivers
• formats

• MS Office
• component COM
• Java Beans
• .NET

30
From Component Systems to Programming Languages
31
From Component Systems to PLs

• component-oriented programming
• different than OOP
• different than modules
• VM (virtual machines) for extensible systems of
  components
• more than a virtual machine
• contracts for components

32
Component Software, Szyperski

• A component is
• a unit of independent deployment
• a unit of third-party composition
• a blueprint without state

Szyperski, page 30
33
COP and Languages Linguistic Support

• parameterization over
• imported components
• exchange of values, including critical pieces
• linking
• graph-based (mutual references)
• hierarchical
• dynamic (first-class values in core)
• multi-lingual components

34
COP and Languages Virtual Machines

• a VM for many languages
• a VM for dynamic extensions
• a VM for non-cooperative extensions

35
COP and Languages Quality Assurance

• components exchange values, including objects and
  functions
• components must protect these values and must
  promise certain properties
• types
• (partial) functional specifications
• concurrency specifications
• QoS guarantees

36
Linguistic Support for COP

• with Matthew Flatt, Robby Findler, Shriram
  Krishnamurthi
• and a little bit of help from Dan Friedman

37
Existing Language Support for Components
Which language constructs should we use to
support programming with components?
38
Existing Language Support for Components
Proposal Use first-class procedures and arrange
them in patterns. Pro hierarchical linking,
dynamic invoking, by-reference passing work
Cons the granularity is too far off.
Maintaining linking patterns by hand is error
prone.
39
Existing Language Support for Components
Proposal Use classes and objects as
components. Pro larger granularity, contains
many functions, protection, dynamic
loading Cons The super-class is hard-wired,
i.e., no parameterization. It is impossible
to wire-in the same class many times.
Inheritance poses programming and contract
checking problems (Szyperski).
40
Existing Language Support for Components
Proposal Use Modula-style modules, Java-style
packages, or C-style assemblies. Pro proper
granularity Cons modules are too static
(compile-time). Importing is hard-wired. They
are not first-class values.
41
Existing Language Support for Components
Proposal Use ML-style functors. They find
good uses in SML and OCAML. Pro They are
parameterized over their importing modules, by
definition. Cons they are not values. It is
not possible to link them in a graphical
manner. Like plain modules, they are static and
not dynamically linkable.
42
PLTs Components Units
Units are first-class values

• Units are parameterized over
• imported components
• references to values
• Units are linked in
• graph-based
• hierarchical
• dynamic manner

43
Units A Language Constructs for COP
44
Units A Language Constructs for COP
example
45
Units Graphical Linking
46
Units Hierarchical Linking
47
Units Dynamic Linking
48
Units Flatt Felleisen

• PLTs units support COP well.
• linking together components is flexible, with
  rich control
• widely used in Version 103
• But there are open problems

49
Units A Program Design Problem

• Given a component with
• a datatype T with N variants
• a collection F of M functions on T
• Wanted extend T with variants and F with
  additional functions without access to the source
  of the component

Krishnamurthi, Felleisen, Friedman
50
Units A Program Design Problem

• Why does it matter?
• abstract reasons
• examples
• How do we do it?
• where units work
• where we need more

51
Units Extensibility - Why?

• maintenance fix once, fix everywhere
• extensibility add functionality once, add it
  everywhere

52
Unit Extensibility Example 1

• DrScheme Krishnamurthi et alli the language
  hierarchy and the set of tools
• datatype is a grammar
• tools syntax check, type check, stepper, and
  more to come

53
Unit Extensibility Example 2

• Geometry server Hudak, Darpa productivity study
• datatype describes arrangements of geometric
  shapes
• tools containment, drawing, moving and many
  others

54
Unit Extensibility Example 3

• San Francisco project Bohrer, IBM
• datatype describes customer, manager, account
  hierarchies
• tools back office maintenance tools

55
Unit Extensibility The Picture
The Core Component
datatype t
f t -gt g -gt t h t -gt t

56
Unit Extensibility The Picture
The Variant Extension
datatype t
f t -gt g -gt t h t -gt t

f, g, h extended
57
Unit Extensibility The Picture
The Functionality Extension
datatype t
f t -gt g -gt t h t -gt t

f, g, h extended
j t -gt t ..
k t -gt t ..
58
Unit Extensibility The Picture
The Full Component
datatype t
self-reference (has-a)
f t -gt g -gt t h t -gt t

f, g, h extended
self call
j t -gt t ..
k t -gt t ..
59
Unit Extensibility The Experience

• Units work well for extensibility
• just re-link for each extension
• each layer around a given component is just an
  adapter unit (Lieberherr Lorenz 01)

60
Unit Extensibility The Experience

• Units alone are not enough
• need lasses to specify datatypes
• and mixins for extensions

61
Unit Extensibility The Experience
Interfaces dont know superclass -- mixin
The Full Component
datatype t
f t -gt g -gt t h t -gt t

f, g, h extended
j t -gt t ..
k t -gt t ..
Findler Flatt
62
Unit Extensibility The Experience

• Linking with units is complex
• Units do not support multiple languages
• PLT also introduced modules.

63
Component-Oriented Programming

• modules for multi-lingual programs
• units for complex linking
• mixins for specifying and working with data
  hierarchies plus implementation inheritance

64
Components in Languages Research Problems

• still complex can we simplify this world?
• practical experience
• units and modules feel inside out
• type systems what will a flexible type system
  for units and modules look like?
• mixins (Krishnamurthi)
• sharing by specification (Flatt)

65
Virtual Machines for COP Resource Administration

• with Matthew Flatt, Robby Findler, Shriram
  Krishnamurthi

66
Resource Administration The Situation

• a dynamic plug-in component is probably
  third-party code with unknown properties
• several plug-ins may run in parallel
• plug-ins compete for finite resources
• files, database servers
• network connections
• GUI items

67
Resource Administration Example 1

• a Web server responds to many requests
  simultaneously each may spawn a Web program
• sharing (communicating) with server
• sharing among scripts
• a script consumes
• time
• memory
• (references to) server stacks
• ports, files, databases,

68
Resource Administration Example 2

• DrScheme runs student programs as dynamic
  extensions so that tools can directly communicate
  with executing programs
• a program consumes
• time
• memory
• GUI windows,
• ports, files, databases,

69
Resource Administration Example 3

• Netscape runs Java applets as dynamic extensions
  so that
• a program consumes
• time
• memory
• GUI windows,
• ports, files, databases,

70
Resource Administration PLs as OSes

• an extensible component system must play OS for
  its plug-ins
• the underlying VM must provide mechanisms for
  resource control
• the underlying programming language must dress
  these mechanisms as language constructs

71
Resource Administration PLTs Solution

• dynamic components as threads
• threads are a resource
• all resources are managed in a custodian

72
Resource Administration Custodians
current custodian
custodian shutdown
thread 3
thread 1
thread 2
network port 2
network port 1
73
Resource Administration Experience

• custodians work well in DrScheme and the Web
  server
• special custodians for GUI because we need to
  manage GUI events (event spaces)

74
Resource Administration Problems

• Custodians dont deal with memory. (Flatt)
• Custodian actions are fixed. Can we specify them?
  
• Other OS services?
• Update code dynamically? (Krishnamurthi)

75
Resource Administration

• In the past, advanced languages provided memory
  administration (garbage collection). Java has
  introduced GC into the mainstream.
• In the future, advanced languages will provide
  other resource administration tools. .NET will
  provide meta-data with assemblies.

76
Enforcing Invariants in COP

• with Robby Findler, Mario Latendresse

77
Contract for Components The Problem
The System
A Plugin
78
Contract for Components The Problem
The System consists of many components.
The System
A Plugin
If it blows up, who did it? Economics!
79
Contracts for Components The Idea

• need behavioral contracts in addition to type
  signatures for external wires of components
• must monitor these assertions at run-time (or
  partially verify them)
• assign blame to faulty component

80
Contracts for ComponentsEiffel

• design by contract a la
• Eiffel, iContract, jContractor, HandShake,
  JVMAssert,
• get it right, scale to other constructs
• then scale to COP

81
Contracts for Components Example
partial behavior
double square_root(double x) _at_pre x gt
0 _at_post fn result -gt result gt 0
total behavior
double square_root(double x) _at_pre x gt
0 _at_post fn x -gt fn result -gt x x gt result
gt 0
82
Contracts for Components Meaning and Blame

• test pre-conditions for method call, blame caller
  
• test post-condition for method return, blame
  callee
• deal with invariants for variables similarly

83
Contracts for Components Classes and Objects

• classes (or mixins) are in an inheritance
  hierarchy
• method contracts must be related
• test implications for pre/post conditions at
  method call return, blame class extension

84
Contracts for Components Functions

• testing predicates on functions is impossible
• use proxy functions that perform tests for
  first-order types, blame current co-variant party
  for bad arguments and contra-variant party for
  bad result
• switch blame positions with applications

85
Contracts for Components Experience

• contracts are as important as types
• contracts complement types
• properties of arguments (subset of types)
• relating two arguments
• relating two functions in a component

86
Contracts for Components

• OOP and contracts
• FP and contracts
• COP and contracts
• types
• linking graphs, dynamic, hierarchical

87
Summary and Advice
88
Software Systems

• build large systems from components
• in-house
• third party
• different sizes
• plug-in components statically
• plug-in components at run-time

89
Software Systems

• systems have complex interactions
• systems act as quasi-OSes for dynamic plug-ins
• such systems consist of components in many
  languages

90
Programming Languages

• provide VMs that support high-level values and
  value sharing
• provide VMs that support resource administration
  for non-collectible resources
• provide VMs that accommodate many languages

91
Programming Languages

• provide constructs for constructing and linking
  components of all sizes and all shapes
• provide constructs for dynamic extensions,
  support mini-OSes for COP

92
Programming Languages

• provide interfaces with contracts
• check contracts in a well-founded manner
• assign blame properly

93
PLTs Solutions

• modules, units, mixins are a good solution, but
  not the last word
• custodians are a good start toward resource
  administration, but not the last word
• and this slide isnt the last word

94
Advice for Academics PL Research

• build systems, not (just) compilers
• useful and team-sized, e.g., DrScheme
• useful and pair-sized, e.g., Web server
• useful individual scripts
• get customers
• test academic languages with all kinds of
  system use feedback for PL design

95
Advice for Industry

• the JVM was a start it does not accommodate
  other languages easily, it does not administrate
  resources
• the .NET world is made for other languages it
  still lacks resource administration
• these machines are not the last word, they are
  just a start for COP

96
Thank you for Your Attention
now go forth and do some more type research