Successfully reported this slideshow.
Your SlideShare is downloading. ×

Challenges In Dsl Design

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 125 Ad

More Related Content

Slideshows for you (20)

Advertisement

Similar to Challenges In Dsl Design (20)

Advertisement

Recently uploaded (20)

Challenges In Dsl Design

  1. Challenges in DSL Design Sebastian Zarnekow - Sven Efftinge
  2. What do today’s DSL projects look like?
  3. Lots of problems are solved
  4. Lots of problems are solved textual DSL frameworks
  5. Lots of problems are solved textual DSL frameworks graphical DSL frameworks
  6. Lots of problems are solved textual DSL frameworks graphical DSL frameworks nice transformation languages
  7. Lots of problems are solved textual DSL frameworks graphical DSL frameworks nice transformation languages open source IDEs
  8. Lots of problems are solved textual DSL frameworks graphical DSL frameworks nice validation nice transformation languages languages open source IDEs
  9. Lots of problems are solved textual DSL frameworks nice template graphical languages DSL frameworks nice validation nice transformation languages languages open source IDEs
  10. Lots of problems are solved textual DSL frameworks nice template graphical languages DSL frameworks proven infrastructure nice validation nice transformation languages languages open source IDEs
  11. In most cases DSLs cover only 80%
  12. ... but what’s missing?
  13. Expressions
  14. Why are expressions missing?
  15. Hiding implementation details?
  16. Information hiding in computer science is the principle of the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed. The protection involves providing a stable interface which shields the remainder of the program from the implementation (the details that are most likely to change). Hiding implementation details?
  17. ation of c Separ once rns?
  18. atio n of c Se par once rns? In computer science, separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors.
  19. • expressions are complicated to implement
  20. • expressions are complicated to implement • expressions of target platform language are already understood
  21. • expressions are complicated to implement • expressions of target platform language are already understood • tooling and libraries can be reused
  22. What’s the price we pay?
  23. Protected Regions
  24. Protected Regions • generated and manually written code mixed up
  25. Protected Regions • generated and manually written code mixed up • manual deletion of artifacts
  26. Protected Regions • generated and manually written code mixed up • manual deletion of artifacts • platform dependent information
  27. Protected Regions • generated and manually written code mixed up • manual deletion of artifacts • platform dependent information • information is dispersed!
  28. Generation Gap Pattern
  29. Generation Gap Pattern technically required type hierarchies
  30. Generation Gap Pattern technically required type hierarchies additional complexity
  31. Generation Gap Pattern technically required type hierarchies additional complexity platform dependent information
  32. Generation Gap Pattern technically required type hierarchies additional complexity platform dependent information information dispersed!
  33. Black box target language literals
  34. Black box target language literals • bound to target platform
  35. Black box target language literals • bound to target platform • no option for MDA friends
  36. Black box target language literals • bound to target platform • no option for MDA friends • no tooling!
  37. Black box target language literals • bound to target platform • no option for MDA friends • no tooling! • long turnarounds!
  38. reuse target platform developers know it libraries very good tooling proven dispersed information complexity in code generation hard to built interpreters
  39. reuse target platform developers know it libraries very good tooling proven dispersed information complexity in code generation hard to built interpreters
  40. reuse target platform developers know it libraries very good tooling proven dispersed information complexity in code generation hard to built interpreters
  41. reuse target platform developers know it libraries very good tooling proven dispersed information complexity in code generation hard to built interpreters
  42. reuse target platform developers know it libraries very good tooling proven dispersed information complexity in code generation hard to built interpreters
  43. reuse target platform developers know it libraries very good tooling proven dispersed information complexity in code generation hard to built interpreters
  44. reuse target platform developers know it libraries very good tooling proven dispersed information complexity in code generation hard to built interpreters
  45. reuse target platform developers know it libraries very good tooling proven dispersed information complexity in code generation hard to built interpreters
  46. reuse target platform invent expressions developers know it non-dispersed information libraries very complex very good tooling very expensive relatively low potential for proven further abstraction dispersed information complexity in code generation hard to built interpreters
  47. reuse target platform invent expressions developers know it non-dispersed information libraries very complex very good tooling very expensive relatively low potential for proven further abstraction dispersed information complexity in code generation hard to built interpreters
  48. reuse target platform invent expressions developers know it non-dispersed information libraries very complex very good tooling very expensive relatively low potential for proven further abstraction dispersed information complexity in code generation hard to built interpreters
  49. reuse target platform invent expressions developers know it non-dispersed information libraries very complex very good tooling very expensive relatively low potential for proven further abstraction dispersed information complexity in code generation hard to built interpreters
  50. reuse target platform invent expressions developers know it non-dispersed information libraries very complex very good tooling very expensive relatively low potential for proven further abstraction dispersed information complexity in code generation hard to built interpreters
  51. Reusing Target Platform • seems reasonable & pragmatic • good compromise
  52. But what if ...
  53. But what if ... reuse target platform expression as library developers know it non-dispersed information libraries nicer expression language - closures very good tooling - type inference proven - operator overloading dispersed information extendable (e.g. custom literals) complexity in code generation good tooling hard to built interpreters additional learning curve
  54. But what if ... reuse target platform expression as library developers know it non-dispersed information libraries nicer expression language - closures very good tooling - type inference proven - operator overloading dispersed information extendable (e.g. custom literals) complexity in code generation good tooling hard to built interpreters additional learning curve
  55. But what if ... reuse target platform expression as library developers know it non-dispersed information libraries nicer expression language - closures very good tooling - type inference proven - operator overloading dispersed information extendable (e.g. custom literals) complexity in code generation good tooling hard to built interpreters additional learning curve
  56. But what if ... reuse target platform expression as library developers know it non-dispersed information libraries nicer expression language - closures very good tooling - type inference proven - operator overloading dispersed information extendable (e.g. custom literals) complexity in code generation good tooling hard to built interpreters additional learning curve
  57. But what if ... reuse target platform expression as library developers know it non-dispersed information libraries nicer expression language - closures very good tooling - type inference proven - operator overloading dispersed information extendable (e.g. custom literals) complexity in code generation good tooling hard to built interpreters additional learning curve
  58. But what if ... reuse target platform expression as library developers know it non-dispersed information libraries nicer expression language - closures very good tooling - type inference proven - operator overloading dispersed information extendable (e.g. custom literals) complexity in code generation good tooling hard to built interpreters additional learning curve
  59. What are the challenges?
  60. concrete syntax grammar mixing abstract syntax meta model reuse constraints static analysis and validation execution time compiler and interpreter development time IDE support
  61. concrete syntax grammar mixing abstract syntax meta model reuse constraints static analysis and validation execution time compiler and interpreter development time IDE support
  62. concrete syntax grammar mixing abstract syntax meta model reuse constraints static analysis and validation execution time compiler and interpreter development time IDE support
  63. concrete syntax grammar mixing abstract syntax meta model reuse constraints static analysis and validation execution time compiler and interpreter development time IDE support
  64. concrete syntax grammar mixing abstract syntax meta model reuse constraints static analysis and validation execution time compiler and interpreter development time IDE support
  65. concrete syntax grammar mixing abstract syntax meta model reuse constraints static analysis and validation execution time compiler and interpreter development time IDE support
  66. concrete syntax grammar mixing abstract syntax meta model reuse constraints static analysis and validation execution time compiler and interpreter development time IDE support
  67. concrete syntax grammar mixing abstract syntax meta model reuse constraints static analysis and validation execution time compiler and interpreter development time IDE support
  68. concrete syntax grammar mixing abstract syntax meta model reuse constraints static analysis and validation execution time compiler and interpreter development time IDE support
  69. concrete syntax grammar mixing abstract syntax meta model reuse constraints static analysis and validation execution time compiler and interpreter development time IDE support
  70. Concrete syntax
  71. Concrete syntax • scan the document for tokens • build a parse result from tokens
  72. Concrete syntax • scan the document for tokens • build a parse result from tokens
  73. Concrete syntax • scan the document for tokens contextless context- • build a parse result from tokens aware
  74. Concrete syntax • scan the document for tokens contextless context- • build a parse result from tokens aware
  75. package org.foo;
  76. package org.foo; Keyword package
  77. package org.foo; Keyword WS package
  78. package org.foo; Keyword WS ID package org
  79. package org.foo; Keyword WS ID K eyword package org .
  80. package org.foo; Keyword WS ID K eyword ID package org . foo
  81. package org.foo; o rd Keyword WS ID K eyword ID yw Ke package org . foo ;
  82. package org.foo; o rd Keyword WS ID K eyword ID yw Ke package org . foo ; PackDecl: “package” ID (‘.’ ID)*’;’
  83. What’s reusable?
  84. What’s reusable? • use rules of other language
  85. What’s reusable? • use rules of other language • specialize rules of other language
  86. What’s reusable? • use rules of other language • specialize rules of other language • introduce new rules
  87. Extensible syntax? Ambiguity!
  88. Extensible syntax? Ambiguity! • alternatives may be conflicting
  89. Extensible syntax? Ambiguity! • alternatives may be conflicting • static analysis can help
  90. package org.foo; o rd Keyword WS ID K eyword ID yw Ke package org . foo ; PackDecl: “package” ID (‘.’ ID)*’;’
  91. package org.foo; package org.assert; o rd Keyword WS ID K eyword ID yw Ke package org . foo ; PackDecl: “package” ID (‘.’ ID)*’;’
  92. package org.foo; package org.assert; o rd Keyword WS ID K eyword yw Ke package org . ; PackDecl: “package” ID (‘.’ ID)*’;’
  93. package org.foo; package org.assert; o rd Keyword WS ID K eyword Keyword eyw K package org . assert ; PackDecl: “package” ID (‘.’ ID)*’;’
  94. What can we do?
  95. What can we do? • scannerless parsing
  96. What can we do? • scannerless parsing • contextual lexing
  97. package org.foo; package org.assert; o rd Keyword WS ID K eyword Keyword eyw K package org . assert ; PackDecl: “package” ID (‘.’ ID)*’;’
  98. package org.foo; package org.assert; o rd Keyword WS ID K eyword Keyword eyw K package org . assert ; PackDecl: “package” ID (‘.’ ID)*’;’
  99. package org.foo; package org.assert; o rd Keyword WS ID K eyword Keyword eyw ID! K package org . assert ; PackDecl: “package” ID (‘.’ ID)*’;’
  100. Context-aware scanning can be confusing
  101. Context-aware scanning can be confusing import “http://namespace/” as generate import “http://namespace/” as alias import “http://namespace/” as generate import “http://namespace/” as alias
  102. Context-aware scanning can be confusing Import: import “http://namespace/” as lias generate import ort ‘U RI’ as a imp “http://namespace/” as alias nerate: “http://namespace/” s algenerate Ge import as ias te name ‘URI’ a as alias import “http://namespace/” genera
  103. Context-aware scanning can be confusing import “http://namespace/” as generate import “http://namespace/” as alias import “http://namespace/” as generate import “http://namespace/” as alias
  104. Be cautious! • be careful with new keywords • minimize set of terminals • think about extensibility
  105. Abstract syntax
  106. Abstract syntax meta models are frozen
  107. Linking
  108. Linking • inter & intra language
  109. Linking • inter & intra language • to platform elements
  110. Linking • inter & intra language • to platform elements • reachable elements
  111. Validation
  112. Validation • inherited
  113. Validation • inherited • invariants may not be weakened
  114. Validation • inherited • invariants may not be weakened • contract for compiler and interpreter
  115. And then there are... • compilers • interpreters • IDE infrastructure • code completion • formatting • label provider
  116. How can we add and change implementation non-invasively?
  117. Example: Customizing the LabelProvider public class MySpecialLabelProvider extends BaseLanguageLabelProvider { public String label(Entity e) { return e.getName(); } public String label(Feature f) { return f.getName()+":"+f.getType().getName(); } } ‣naming convention ‣polymorphic dispatch
  118. Available June 24th.
  119. Thank you very much! www.itemis.com www.xtext.org

×