Language and Ontology

1
Language and Ontology

• Shriram Krishnamurthi
• Yan-David Erlich
• Matthias Felleisen
• Rice University

2
Language and Perception

• Different programming styles influence the way we
  think about the world
• Therefore, programmers want to extend their
  languages to suit their problem domains
• Consequence programmers define new languages all
  the time!

3
Adaptive ProgrammingOverview
Lieberherr, et al
4
Adaptive ProgrammingTraversals

• Traversal
• from BusRoute
• to Person
• through BusStop

5
Software PatternsOverview

• Concrete versions of design patterns
• Allow high-level descriptions of creational,
  behavioral and structural properties
• Map pattern instances to code
• (Definition and mapping should respect the
  inductive structure of patterns)

Gamma, Helm, Johnson, Vlissides, and others
6
Software PatternsExample

• Adapter Pattern

Adapter
7
Software Patterns Adaptive Programming

• Behaviors are described by the Visitor Pattern,
  but it has lots of syntactic overhead

Visitor BusWaiterVisitor BusRoute -gt
BusStop -gt Person -gt
8
Scientific ComputationMatrices Overview

• Implementation uses C templates
• Two languages are involved
• configuration (extensional)
• element type (float, complex, )
• shape (upper triangular, symmetric, )
• implementation specification (intensional)
• bounds checked (yes, no)
• optimize for (speed, size)

Czarnecki, Eisenecker, et al
9
Summary

• Examples of the growing influence of
  domain-specific languages (DSLs)
• DLSs are a way to institutionalize knowledge and
  make it common to all the programmers in an
  organization/domain
• Some DSLs are created afresh many leverage
  existing languages

10
Are DSLs APIs?

• begin_scope ()
• end_scope ()

create_scoped_variable (x) access_scoped_vari
able (x)
(This is a terrible language!)
Similar examples in COM, etc
11
Typical Needs

• New binding forms
• Different orders of evaluation (applicative vs
  normal, right-to-left, etc)
• Domain-specific notations, conventions
• Programmers use libraries because thats all they
  have available!

12
Roadmap

• Needs a combination of support from the
  programming language and environment
• Easy and powerful definitions
• Tight integration of language extensions
• Preservation of language abstractions
• Powerful implementation model

13
Adaptive ProgrammingRecap

• Visitor
• BusWaiterVisitor
• BusRoute -gt
• BusStop -gt
• Person -gt

14
Tool Support forAdaptive Programming

• Combining these specifications

Error!
The adaptive programming tool does not know about
our pattern extensions
Sometimes, there is no ordering of DSLs
Result users must choose between DSLs
15
RequirementTight Integration

• External tools cannot be composed
• External tools may provide poor debugging support
• Integrated tools may require the environment to
  be re-built for every addition or change
• Important consideration
• Easy prototyping

16
The Middle Ground

• Start with macro systems a la Scheme
• A macro system is a rewriting engine that works
  on a term structured syntax
• The macro language is embedded into a host
  language
• Multiple extensions can co-exist

17
Definition Facility
(define-macro Adapter (rewrite (_ ltaNgt adapts
ltaTgt to ltdIgt as ltaVgt
(fields ltfdgt ) (methods ltmdgt ))
(as (class ltaNgt implements ltdIgt (fields
(ltaTgt ltaVgt) ltfdgt ) (methods ltmdgt ))))
18
Macros as Transformers
19
RequirementPreserve Abstractions

• Embedding languages would not be effective if the
  programmer did not get information in terms of
  what they wrote

(Information type errors, program slices, value
flow graphs, etc)
20
Why This Matters

• MultiplicationExpressionltclass LazyBinaryExpressio
  nltclass AdditionExpressionltclass
  MatrixICCLMatrixltclass MatrixICCLBoundsChecker
  ltclass MatrixICCLArrFormatltclass
  MatrixICCLStatExtltstruct MatrixDSLint_numberlti
  nt,7gt,struct MatrixDSLint_numberltint,7gtgt,class
  MatrixICCLRectltclass MatrixICCLStatExtltstruct
  MatrixDSLint_numberltint,7gt,struct
  MatrixDSLint_numberltint,7gtgtgt,class
  MatrixICCLDyn2DCContainerltclass
  MATRIX_ASSEMBLE_COMPONENTSltclass
  MATRIX_DSL_ASSIGN_DEFAULTSltclass
  MATRIX_DSL_PARSERltstruct MatrixDSLmatrixltint,str
  uct MatrixDSLstructureltstruct
  MatrixDSLrectltstruct MatrixDSLstat_valltstruct
  MatrixDSLint_numberltint,7gtgt,struct
  MatrixDSLstat_valltstruct MatrixDSLint_numberlti
  nt,7gtgt,struct MatrixDSLunspecified_DSL_featuregt,
  struct MatrixDSLdenseltstruct MatrixDSLunspecif
  ied_DSL_featuregt,struct MatrixDSLdynltstruct
  MatrixDSLunspecified_DSL_featuregtgt,struct
  MatrixDSLspeedltstruct MatrixDSLunspecified_DSL
  _featuregt,struct MatrixDSLunspecified_DSL_featur
  e,struct MatrixDSLunspecified_DSL_feature,struct
  MatrixDSLunspecified_DSL_feature,struct
  MatrixDSLunspecified_DSL_featuregtgtDSLConfiggt
  DSLConfiggtgtgtgtgt,class MatrixICCLMatrixltclass
  MatrixICCLBoundsCheckerltclass
  MatrixICCLArrFormatltclass MatrixICCLStatExtltst
  ruct MatrixDSLint_numberltint,7gt,struct
  MatrixDSLint_numberltint,7gtgt,class
  MatrixICCLRectltclass MatrixICCLStatExtltstruct
  MatrixDSLint_numberltint,7gt,struct
  MatrixDSLint_numberltint,7gtgtgt,class
  MatrixICCLDyn2DCContainerltclass
  MATRIX_ASSEMBLE_COMPONENTSltclass
  MATRIX_DSL_ASSIGN_DEFAULTSltclass
  MATRIX_DSL_PARSERltstruct MatrixDSLmatrixltint,str
  uct MatrixDSLstructureltstruct
  MatrixDSLrectltstruct MatrixDSLstat_valltstruct
  MatrixDSLint_numberltint,7gtgt,struct
  MatrixDSLstat_valltstruct MatrixDSLint_numberlti
  nt,7gtgt,struct MatrixDSLunspecified_DSL_featuregt,
  struct MatrixDSLdenseltstruct MatrixDSLunspecif
  ied_DSL_featuregt,struct Ma

Generated from (A B) C
21
Alternative
22
Maintaining Abstractions

• Source correlation
• Ability to track source information through
  expansions
• Helps programmers understand feedback in terms of
  original source

23
Interacting Abstractions

• Elaboration tracking
• Keeps track of history of transformations on
  terms
• Helps designers (and programmers) debug in the
  presence of complex interactions

24
RequirementGeneralize Domain

• Even common languages have lots of little
  languages in them
• Macros are often limited to the expression and
  definition language
• (define (factorial (int n) int)
• )
• Expansion uses a protocol to determine latest
  version of each language

25
RequirementGeneralize Expansion

• Macros are traditionally source-to-source
  generalize by
• giving control over expansion of sub-expressions
• allowing intermediate stages to produce
  non-source output
• enriching with attribute specifications (both
  threaded and unthreaded)

26
Recap

• What we have described is a generalization of
  macros to extend to full compilation
• Macros
  Compilers

• We provide both mechanism and policy
• several incremental stages
• common framework, so designers can combine these
  in a single specification

27
RequirementModularize Languages

• Languages are defined as vocabularies
• These have abstract parent languages
• Designers can compose them to create complete
  languages
• (analogous to mixins for classes)
• This makes specifications much more coherent and
  reusable

28
Languages as Layers
DL3
DL3
DL2
DL1
DL1
Base Language 2
Base Language 1

• Base Language 1

29
Summary

• Experience shows our system is
• practical and efficient
• Key features
• definition conveniences (, hygiene)
• source correlation
• macros-to-compilers continuum
• language mixins

30
Conclusion

• We have
• made a case for extensible languages
• described several challenge features to demand
  of programming environments
• mentioned how we implement these features