A Little Language for Surveys: Constructing an Internal DSL in Ruby H. Conrad Cunningham Computer and Information Science University of Mississippi

2 Domain-Specific Language (DSL) “programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain” – van Deursen, Klint, and Visser “programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain” – van Deursen, Klint, and Visser “little language” – J. Bentley “little language” – J. Bentley

3 Typical DSL Characteristics Not general-purpose Not general-purpose Small (at least initially) Small (at least initially) Declarative Declarative Semantically expressive of domain Semantically expressive of domain Targeted at domain specialists, not necessarily programmers Targeted at domain specialists, not necessarily programmers

4 External or Internal External: different from main programming language –make, yacc, pic, XML-based config files Internal (embedded): constrained use of the main programming language –use of Lisp macros, Haskell algebraic types, metaprogramming in Ruby, etc.

5 Defining Internal DSLs in Ruby (1 of 2) Flexible syntax enables convenient DSL statements –optional parentheses on method calls –variable number of arguments question“Male or female?” # has optional second arg

6 Defining Internal DSLs in Ruby (2 of 2) Blocks (closures) provide DSL structuring and delayed execution –anonymous function definitions –passed as arguments question “Male or female?” do response “Male” response “Female” = true end end

7 Implementing Internal DSLs in Ruby (1 of 2) Reflexive metaprogramming: writing programs that manipulate themselves as data obj.instance_eval(str) executes string str as Ruby code in context of object obj obj.instance_eval(str) executes string str as Ruby code in context of object obj –execute DSL statements dynamically mod.class_eval(str) executes string str as Ruby code in context of module mod mod.class_eval(str) executes string str as Ruby code in context of module mod –declare new methods and classes dynamically

8 Implementing Internal DSLs in Ruby (2 of 2) obj.method_missing(sym,*args) invoked when undefined method sym called with arguments args obj.method_missing(sym,*args) invoked when undefined method sym called with arguments args –take remedial action obj.send(sym,*args) calls method sym on object obj with arguments args obj.send(sym,*args) calls method sym on object obj with arguments args –dynamically “send a message”

9 Little Language for Surveys Domain: Specification and presentation of simple, multiple-choice surveys Tasks: 1. Analyze domain for language design 2. Design Ruby internal DSL 3. Implement DSL

Domain Analysis

11 Commonality/Variability Analysis Determine domain boundaries (scope) Determine domain boundaries (scope) Define specialized terms and concepts (terminology) Define specialized terms and concepts (terminology) Identify unchanging features among domain members (commonalities) Identify unchanging features among domain members (commonalities) Identify features that may change among domain members (variabilities) Identify features that may change among domain members (variabilities)

12 Scope Support definition of simple, multiple- choice surveys Support definition of simple, multiple- choice surveys –specification of survey –presentation of survey and collection of responses Exclude tabulation of aggregate results for now Exclude tabulation of aggregate results for now

13 Terms and Commonalities 1. Survey has a title 2. Survey has a sequence of questions 3. Question has a sequence of responses 4. Use of conditional question depends upon previous responses 5. Response to silent question determined from previous responses 6. Survey execution presents appropriate questions to respondent and collects choices of responses

14 Variabilities 1. Texts for title, questions, and responses 2. Number and order of questions within survey 3. Number of responses expected for question 4. Number and order of responses in question 5. Condition under which question included 6. Method for answering silent question 7. Source of survey specification 8. Method for displaying questions and collecting responses during execution

Internal DSL Design

16 DSL Design Strategy Adopt declarative approach – structure explicit but processing implicit Adopt declarative approach – structure explicit but processing implicit Use terminology and commonalities to suggest language statements Use terminology and commonalities to suggest language statements Represent variabilities as values that survey programmers supply Represent variabilities as values that survey programmers supply

17 Survey DSL Example (1 of 3) # C1 survey has title (V1) title “ACMSE Survey” # C2 survey has seq of questions (V2) question “Are you an author?” do # (V3) # C3 question has seq of responses (V4) # C3 question has seq of responses (V4) response "Yes" do # execute if chosen response "Yes" do # execute if = = true end end response “No” do # execute if chosen response “No” do # execute if = = false end endend

18 Survey DSL Example (2 of 3) # C4 conditional question (V5) question "What type of paper?" do condition } # when execute? condition } # when execute? response "Regular" = :rg end response "Regular" = :rg end response "Student" = :st end response "Student" = :st end response "Work-in-progress" do response "Work-in-progress" = = :wp end end # V5/V6 block on response & action sets # V5/V6 block on response & action sets # state for conditions & silent choices # state for conditions & silent choices action = = 15 == :wp} action = = 15 == :wp}end

19 Survey DSL Example (3 of 3) # C5 silent question calculates choice (V6) result "How long is presentation?“ do condition } condition } alternative "25" do # when choose? alternative "25" do # when == :rp == == :rp == :sp end end alternative “15” do # when choose? alternative “15” do # when == == :wp end endend

Internal DSL Implementation

21 Two-Pass Implementation 1. Parse DSL and build abstract syntax tree (AST) 2. Execute survey by traversing AST

22 First Pass: DSL Parsing Use instance_eval to execute DSL input as Ruby code (V7) Use instance_eval to execute DSL input as Ruby code (V7) Let Ruby interpreter do most of parsing Let Ruby interpreter do most of parsing Add methods for each DSL statement – title, question, action, etc. Add methods for each DSL statement – title, question, action, etc. Check specialized syntax and build AST as 3-level tree (survey, question, response) Check specialized syntax and build AST as 3-level tree (survey, question, response) Defer conditions and actions by storing unevaluated blocks Defer conditions and actions by storing unevaluated blocks

23 Second Pass: DSL Interpretation Traverse AST to display questions and collect responses Traverse AST to display questions and collect responses Execute deferred blocks needed for conditions and actions Execute deferred blocks needed for conditions and actions Use missing_method and class_eval to create reader/writer methods for variables in blocks Use missing_method and class_eval to create reader/writer methods for variables in blocks

24 Architecture First pass – use Object Scoping and Context Variable patterns for safety and flexibility, Deferred Evaluation for actions Second pass – use Visitor pattern for flexibility (C6, V8)

25 Summary Illustrated how commonality/variability analysis can be adapted for DSL design Illustrated how commonality/variability analysis can be adapted for DSL design Demonstrated how Ruby facilities can be used for internal DSL development Demonstrated how Ruby facilities can be used for internal DSL development Explored how design patterns can help lead to safe and flexible DSL processors Explored how design patterns can help lead to safe and flexible DSL processors

26 Future Work More systematic techniques to explore domain and discover needed constructs More systematic techniques to explore domain and discover needed constructs Improved runtime error handling tied to DSL input Improved runtime error handling tied to DSL input Better facilities for user extension Better facilities for user extension Investigation and comparison of other languages – Groovy, Scala, Haskell Investigation and comparison of other languages – Groovy, Scala, Haskell

27 Acknowledgements Members of Fall 2006 graduate class on Ruby and Software Development Members of Fall 2006 graduate class on Ruby and Software Development Suggestions on the paper by several current and former students Suggestions on the paper by several current and former students

28 Questions