Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

What's Missing in Language Workbenches


Published on

In this talk I will present a number of issues that we run against in our work of building DSLs for and with customers, mostly on top of MPS. This is not an MPS wishlist, but rather the attempt at identifying general areas where tool support or even the conceptual approach are not yet as mature as for the basics of language engineering: syntax, type systems, generators and basic IDE support. An ideal outcome of this session would be the formation of groups of people who will work on some of these issues in the future. These issues include the construction of debuggers for various language paradigms, realtime incremental transformations of models, interactive guidance for end users (clippy for DSLs :-)), a practically-usable formalism for defining semantics from which interpreters and generators can be derived, as well as the more diffuse requirement for more “liveness” in DSLs of non-trivial complexity and model sizes.

Published in: Software
  • Be the first to comment

  • Be the first to like this

What's Missing in Language Workbenches

  1. 1. Markus Völter @markusvoelter What‘s missing?
  2. 2. Realtime Incremental Transformations 1
  3. 3. What is Shadow Models? Functional transformation language with support for fixpoints Incremental execution upon change of input model Unidirectional, but with first-class support for lifting results Fully integrated into MPS IDE Code: Docs:
  4. 4. Mechanics Input Model Shadow Model ... ‚ User edits the input model A delta is propagated into the transformation engine A change on the shadow model is produced This triggers analysis or update of results in Shadow Model Results/messages are lifted back to input level Results are annotated to the input model Mightbestacked
  5. 5. Current State (March 2019) Still under active development. Primarily by Sascha Lisson. Used for initial use cases at itemis Stuttgart.
  6. 6. Kf2 Core Interpreter Generator Verifier Sugar DSL1 DSL2 DSL3 ShadowModels • Minimal, Expressive Core • Functional • Reactive • Sugar on top • Interpter, Generator and Verifier below • Realtime-Trafo with Shadow Models
  7. 7. Example Input
  8. 8. Example Shadow
  9. 9. Example Use Cases • Mapping of system models to model checkers for interactive verification of temporal properties • Flattening of component hierarchies for type checking • Flattening of hierarchical feature models for path expression evaluation • Weaving in of safety concerns into C code. • Desugaring of business DSLs to a core functional language; that core language would then feature an interpreter, a compiler and an integration with an SMT solver
  10. 10. Use Case: Safety Patterns
  11. 11. Use Case: Safety Patterns +
  12. 12. Use Case: Safety Patterns + =
  13. 13. Use Case: Interactive FM Specialization Klaus Birken
  14. 14. Use Case: Interactive FM Specialization Klaus Birken Uncheck Hybrid
  15. 15. Use Case: Interactive FM Specialization Klaus Birken Check Combustion
  16. 16. Use Case: Interactive FM Specialization Klaus Birken Check RearCamera
  17. 17. Guidance 2
  18. 18. Applications Modeling Toolvs. But not like that! Novice Users need Guidance!
  19. 19. Applications Modeling Toolvs. Novice Users need Guidance! What am I working on? What should I do next? How complete is my model? What is the quality of my model? Roles Tasks, Workflow Model States Metrics Defined jointly with the language.
  20. 20. Semantics 3
  21. 21. Semantics Spec Interpreter Compiler Verifier Functional + Imperative K + FunCons Must be understandable by an engineer, not a mathematician!
  22. 22. Semantics Grow on (imperative) C
  23. 23. KernelF Semantics Solver Model Checker Rules Engine Functional Interpreter Reactive Interpreter Several Projects / DSLs Lots of ideas J Grow on other Foundations! Grow on functional KernelF.
  24. 24. Debuggers 4
  25. 25. Debuggers Different ones for different language paradigms Functional => Tree Imperative => Stepping Declarative => ?
  26. 26. Debuggers Different ones for different language paradigms Functional => Tree Imperative => Stepping Declarative => ? Often the (semantic reverse) of generation it has to recover DSL semantics for watches, views, breakpoints Related to simulators and „model animators“ No good tool support for building them! Realtime vs. Post Mortem
  27. 27. Liveness 5
  28. 28. Beyond Balls and Trees Not too much has happened since the legandary demo. Overlay program execution data Run tests and illustrate results in the background. Instance-based programming (Jonathan Edwards) That‘s it? What else can we do? Which LWB-support can be build?
  29. 29. Explain Communicate Convince 6
  30. 30. Maybe more important! !
  31. 31. Markus Völter @markusvoelter ?