Language and Ontology Shriram Krishnamurthi Yan-David Erlich Matthias Felleisen Rice University

Language and Perception zDifferent programming styles influence the way we think about the world zTherefore, programmers want to extend their languages to suit their problem domains zConsequence: programmers define new languages all the time!

Adaptive Programming: Overview Lieberherr, et al

Adaptive Programming: Traversals Traversal: from BusRoute to Person through BusStop

Software Patterns: Overview zConcrete versions of design patterns zAllow high-level descriptions of creational, behavioral and structural properties zMap pattern instances to code (Definition and mapping should respect the inductive structure of patterns) Gamma, Helm, Johnson, Vlissides, and others

Software Patterns: Example Adapter Pattern += Adapter

Software Patterns + Adaptive Programming Behaviors are described by the Visitor Pattern, but it has lots of syntactic overhead Visitor BusWaiterVisitor { BusRoute -> … BusStop -> … Person -> … }

Scientific Computation: Matrices Overview Implementation uses C++ templates Two languages are involved: zconfiguration (extensional) yelement type (float, complex, …) yshape (upper triangular, symmetric, …) zimplementation specification (intensional) ybounds checked (yes, no) yoptimize for (speed, size) Czarnecki, Eisenecker, et al

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

Are DSLs APIs? begin_scope (); … … … end_scope (); create_scoped_variable (“x”); … access_scoped_variable (“x”); (This is a terrible language!) Similar examples in COM, etc

Typical Needs zNew binding forms zDifferent orders of evaluation (applicative vs normal, right-to-left, etc) zDomain-specific notations, conventions Programmers use libraries because that’s all they have available!

Roadmap Needs a combination of support from the programming language and environment zEasy and powerful definitions zTight integration of language extensions zPreservation of language abstractions zPowerful implementation model

Adaptive Programming: Recap Visitor BusWaiterVisitor { BusRoute -> … BusStop -> … Person -> … }

Tool Support for Adaptive Programming Combining these specifications: The adaptive programming tool does not know about our pattern extensions Result: users must choose between DSLs Sometimes, there is no ordering of DSLs

Requirement: Tight Integration zExternal tools cannot be composed zExternal tools may provide poor debugging support zIntegrated tools may require the environment to be re-built for every addition or change Important consideration: Easy prototyping

The Middle Ground Start with macro systems a la Scheme zA macro system is a rewriting engine that works on a term structured syntax zThe macro language is embedded into a host language zMultiple extensions can co-exist

Definition Facility (define-macro Adapter (rewrite (_ adapts to as (fields …) (methods …)) (as (class implements (fields ( ) …) (methods …))))

Macros as Transformers

Requirement: Preserve 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)

Why This 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… Generated from (A + B) * C

Alternative

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

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

Requirement: Generalize 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

Requirement: Generalize Expansion Macros are traditionally source-to-source; generalize by zgiving control over expansion of sub- expressions zallowing intermediate stages to produce non-source output zenriching with attribute specifications (both threaded and unthreaded)

Recap What we have described is a generalization of macros to extend to full compilation: Macros Compilers We provide both mechanism and policy: zseveral incremental stages zcommon framework, so designers can combine these in a single specification

Requirement: Modularize Languages zLanguages are defined as “vocabularies” zThese have abstract parent languages zDesigners can compose them to create complete languages (analogous to “mixins” for classes) zThis makes specifications much more coherent and reusable

Languages as Layers Base Language 1 Base Language 2  L1  L2  L3 Base Language 1  L1  L3

Summary Experience shows our system is practical and efficient Key features: zdefinition conveniences (…, hygiene) zsource correlation zmacros-to-compilers continuum zlanguage mixins

Conclusion We have zmade a case for extensible languages zdescribed several “challenge” features to demand of programming environments zmentioned how we implement these features