A conceptual framework for building good DSLs. Markus Voelter independent/itemis

Transcription

1 DSL Design A conceptual framework for building good DSLs Markus Voelter independent/itemis voelter@acm.org +Markus Voelter based on material from a paper written with Eelco Visser E.Visser@tudelft.nl

2

3 This material is part of my upcoming (Feb. 2013) book DSL Engineering Designing, Implementing and Using Domain-Specific Laguages Stay in touch; it will be cheap :-)

4

5 Introduction

6 A DSL is a focussed, processable language for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitable for the stakeholders who specify that particular concern.

7 General Purpose C Components State Machines Domain Specific Sensor Access LEGO Robot Control

8 Modular Language my L a b c d e f g h i j k l with many optional, composable modules

9

10 Case Studies

11 Example Compo nents

12 Example Compo nents

13 Example Refrigerators Refrige rators

14 Example Refrige rators

15 Example Refrige rators

16 Example Exten ded C

17 Example Pension Plans

18 Example Pension Plans

19 Example Web DSL

20

21 Terms & Concepts

22 Domain

23 deductive top down body of knowledge in the real world Domain Example Example Refrigerators Penion Plans Refrige rators

24 Domain Domain existing software inductive bottom up Example Example (family) Exten ded C Compo netns

25

26 Programs are trees element

27 Programs are graphs, really. reference

28 Fragments are subtrees w/ root fragment root fragment f

29 Languages are sets of concepts C 1 C 2 C 3 C n L

30 Languages are sets of concepts C 1 C 2 C 3 C n L

31 Programs and languages C 1 C 2 C 3 C n

32 Language: concept inheritance L 1 C 1 C 2 L 2 C 1 C 3

33 Language does not depend on any other language Independence Fragment does not depend on any other fragment

34 Independence Example Refrige rators

35 Homogeneous Fragment everything expressed with one language

36 Heterogeneous C Statemachines Testing Example Exten ded C

37 Domain Hierarchy

38 Domain Hierarchy automotive avionics embedded software all programs Example Exten ded C

39

40 Design Dimensions expressivity coverage semantics separation of concerns completeness paradigms modularity concrete syntax process

41 Expressivity expressivity coverage semantics separation of concerns completeness paradigms modularity concrete syntax process

42 Shorter Programs More Accessible Semantics

43 For a limited Domain! Domain Knowledge encapsulated in language

44 Smaller Domain More Specialized Language Shorter Programs

45 The do-what-i-want language Ѱ

46 Single Program vs. Class/Domain No Variability! Ѱ

47 Domain Hierarchy more specialized domains more specialized languages

48 Reification D n

49 Reification D n+1 == D n

50 Reification Transformation/ Generation Language Definition ==

51

52 Overspecification! Requires Semantic Analysis!

53 Linguistic Abstraction Declarative! Directly represents Semantics.

54 Def: DSL A DSL is a language at D that provides linguistic abstractions for common patterns and idioms of a language at D-1 when used within the domain D.

55 Def: DSL cont d A good DSL does not require the use of patterns and idioms to express semantically interesting concepts in D. Processing tools do not have to do semantic recovery on D programs. Declarative!

56

57 Semantics & Execution expressivity coverage semantics separation of concerns completeness paradigms modularity concrete syntax process

58 Static Semantics Execution Semantics

59 Static Semantics Execution Semantics

60 Static Semantics Constraints Type Systems

61 Unique State Names Unreachable States Dead End States Example Exten ded C

62 Unique State Names Unreachable States Dead End States Easier to do on a declarative Level! Example Exten ded C

63 Unique State Names Unreachable States Dead End States Easier to do on a declarative Level! Thinking of all constraints is a coverage problem! Example Exten ded C

64

65 Assign fixed types Derive Types Calculate Common Types Check Type Consistency What does a type system do?

66 Intent + Derive Check

67 Intent + Derive Check More code Better error messages Better Performance

68 Intent + Derive Check More code Better error messages Better Performance More convenient More complex checkers Harder to understand for users

69 What does it all mean? Execution Semantics

70 Def: Semantics via mapping to lower level OB: Observable Behaviour (Test Cases)

71 Def: Semantics via mapping to lower level L D Transformation Interpretation L D-1

72 Transformation D n+1 D n

73 Transformation Example Exten ded C

74 Transformation L D L D-1 Transformation Known Semantics!

75 Transformation L D Correct!? L D-1 Transformation

76 Transformation Tests (D) Tests (D-1) L D L D-1 Transformation Run tests on both levels; all pass. Coverage Problem!

77 Example Refrige rators

78 Transformation Example Pension Plans

79 Behavior Example Refrige rators

80 Multi-Stage L 3 L 2 Modularization L 1 L 0

81 Multi-Stage: Reuse L 3 L 2 L 5 L 1 Reusing Later Stages L 0 Optimizations!

82 Multi-Stage: Reuse L 3 Robot Control State Machine L 2 L 5 Components L 1 C (MPS tree) L 0 C Text Example Exten ded C

83 Multi-Stage: Reuse L 3 L 2 L 5 Robot Control State Machine Consistency Model Checking Components Efficient Mappings L 0 L 1 C Type System C (MPS tree) Syntactic Correctness, Headers C Text Example Exten ded C

84 Multi-Stage: Reuse L 3 Reusing Early Stages L 2 Portability L 1 L 1b L 0 L 0b

85 Multi-Stage: Reuse L 3 L 2 L 1 L 1b Java C# Example L 0 L 0b Exten ded C

86 Multi-Stage: Preprocess Adding an optional, modular emergency stop feature

87 Interpretation A program at D 0 that acts on the structure of an input program at D >0

88 Interpretation A program at D 0 that acts on the structure of an input program at D >0 imperative step through functional eval recursively declarative? solver?

89 Example Pension Plans

90 Example Refrige rators

91 Behavior Example Refrige rators

92 Transformation Interpretation

93 Transformation Interpretation + Code Inspection

94 Transformation Interpretation + Code Inspection OSGi Generators Example Compo nents

95 Transformation Interpretation + Code Inspection + Debugging

96 Transformation Interpretation + Code Inspection + Debugging Platform Interactions Example Refrige rators

97 Transformation Interpretation + Code Inspection + Debugging + Performance & Optimization

98 Transformation Interpretation + Code Inspection + Debugging + Performance & Optimization Efficiency for Real-Time S/w Memory Use Example Exten ded C

99 Transformation Interpretation + Code Inspection + Debugging + Performance & Optimization + Platform Conformance

100 Transformation Interpretation + Code Inspection + Debugging + Performance & Optimization + Platform Conformance Web Frameworks and Standards Example Web DSL

101 Transformation + Code Inspection Interpretation + Turnaround Time + Debugging + Performance & Optimization + Platform Conformance

102 Transformation + Code Inspection + Debugging Interpretation + Turnaround Time Testing + Performance & Optimization + Platform Conformance Example Pension Plans Example Refrige rators

103 Transformation + Code Inspection + Debugging Interpretation + Turnaround Time + Runtime Change + Performance & Optimization + Platform Conformance

104 Transformation + Code Inspection + Debugging + Performance & Optimization + Platform Conformance Interpretation + Turnaround Time + Runtime Change Change Business Rules without Redeployment Example Pension Plans

105 Def: Semantics via mapping to lower level L D Transformation Interpretation L D-1

106 Multiple Mappings at the same time L D L x L y L z Similar Semantics?

107 Multiple Mappings at the same time L D T Similar Semantics? L x L y L z T T T all green!

108 Example Pension Plans

109 Example Refrige rators

110

111 Reduced Expressiveness bad? maybe. good? maybe!

112 Reduced Expressiveness bad? maybe. good? maybe! Model Checking SAT Solving Exhaustive Search, Proof!

113 Unique State Names Unreachable States Dead End States Guard Decidability Reachability Exhaustive Search, Proof!

114 Example Exten ded C

115 Example Exten ded C

116

117 Separation of Concerns expressivity coverage semantics separation of concerns completeness paradigms modularity concrete syntax process

118 Several Concerns in one domain

119 Several Concerns in one domain integrated into one fragment separated into several fragments

120 Viewpoints independent dependent

121 Viewpoints Hardware Behavior Tests Example Refrige rators

122 Viewpoints: Why? Sufficiency Different Stakeholders Different Steps in Process VCS unit!

123 Viewpoints Hardware Product Management Behaviour Thermodynamics- Experts Tests Example Refrige rators

124 Viewpoints independent sufficient? contains all the data for running a meaningful transformation

125 Viewpoints sufficient Hardware structure documentation sufficient implementation code Example Refrige rators

126 Viewpoints: Why? 1:n Relationships

127 Viewpoints Hardware 1:n Behaviour Tests Example Refrige rators

128 Viewpoints Well-defined Dependencies No Cycles! Avoid Synchronization! (unless you use a projectional editor)

129

130 Language Modularity expressivity coverage semantics separation of concerns completeness paradigms modularity concrete syntax process

131 Language Modularity, Behavior Composition and Reuse (LMR&C) increase efficiency of DSL development

132 Language Modularity, Behavior Composition and Reuse (LMR&C) increase efficiency of DSL development 4 ways of composition: Referencing Reuse Extension Reuse

133 Language Modularity, Behavior Composition and Reuse (LMR&C) increase efficiency of DSL development 4 ways of composition: distinguished regarding dependencies and fragment structure

134 Dependencies: Behavior do we have to know about the reuse when designing the languages?

135 Dependencies: Behavior do we have to know about the reuse when designing the languages? Fragment Structure: homogeneous vs. heterogeneous ( mixing languages )

136 Behavior Dependencies & Fragment Structure:

137

138 Referencing

139 Referencing Dependent No containment

140 Referencing Used in Viewpoints

141 Referencing Fragment Fragment Fragment

142 Referencing Example Refrige rators

143

144 Extension

145 Extension Dependent Containment

146 Extension more specialized domains more specialized languages

147 Extension D n+1 == D n

148 Extension D n+1 == D n

149 Extension Good for bottom-up (inductive) domains, and for use by technical DSLs (people) D n ==

150 Extension Behavior Drawbacks tightly bound to base potentially hard to analyze the combined program

151 Extension Example Exten ded C

152 Extension Example Exten ded C

153

154 Embedding

155 Embedding

156 Embedding Independent Containment

157 Embedding Example Pension Plans

158 Embedding Behavior Embedding often uses Extension to extend the embedded language to adapt it to its new context.

159

160 Concrete Syntax expressivity coverage semantics separation of concerns completeness paradigms modularity concrete syntax process

161 UI for the language! Important for acceptance by users! Textual Symbolic Tabular Graphical

162 Reuse existing syntax of domain, if any! Tools let you freely combine all kinds.

163 Default: Text Editors simple to build Productive Easy to integrate w/ tools Easy to evolve programs

164 Default: Text Editors simple to build Productive Easy to integrate w/ tools Easy to evolve programs then add other forms, if really necessary

165 Graphical in case Relationships

166 Graphical in case Flow and Depenency

167 Graphical in case Causality and Timing

168 Symbolic Either Mathematical, or often highly inspired by domain

169 Tables

170 Combinations

171 Combinations

172 Combinations

173 Combinations

174

175 The +Markus Voelter