The Design, Evolution and Use of KernelF
0 likes64 views
The document discusses the design, evolution, and use of domain-specific languages (DSLs) in various contexts, including healthcare, payroll services, and smart contracts, emphasizing the importance of safety and correctness in software applications. It highlights the development of a new language, Kernelf, built with the JetBrains MPS workbench, which focuses on functional features and robust tooling to support non-programmers. Additionally, the document covers the challenges and considerations in model-driven programming and system architecture to ensure reliable implementations and safety standards.
The Design, Evolution and Use of KernelF
- 1. DESIGN, EVOLUTION AND USE Markus Völter [email protected] www.voelter.de @markusvoelter of KernelF
- 4. Context Mobile Apps that help patients w/ treatments Monitor side-effects and recommend actions Manage dosage of medications
- 5. Context Mobile Apps that help patients w/ treatments Monitor side-effects and recommend actions Manage dosage of medications “Algorithms“ for recommendations and dosage at the core of these apps. Safety-critical, since they could hurt patients. Customer develops many different apps/algos like this, efficiency of algo development is key.
- 8. Some Language Impressions III
- 9. What good is all the abstraction if we cannot trust the translation to the implementation? Execution Architecture
- 10. DESIGN, EVOLUITION AND USE
- 11. 2 Salary + Tax EXAMPLE 2
- 12. Company Context Largest German provider for payroll services. Avoid re-engineering Fachlichkeit whenever technology changes. A DSL to capture and test Fachlichkeit. Execution: Interpreter in the IDE + Code Generator to Java
- 13. DSL Features – Dates and Currencies
- 14. DSL Features – Temporal Data
- 15. DSL Features – Data & Calculations
- 16. DSL Features – Polymorphic Overriding
- 17. DESIGN, EVOLUITION AND USE
- 19. Context For smart contracts to be useful, the people who understand the „contract logic“ have to be able to verify its correctness. High-Level Description Simulation / Testing Verification Core patterns at the core of many SCs: Decisions, Agreements, Auctions.
- 22. Combination with State Machines
- 23. Combintation with State Machines II
- 24. Preventing Game Theoretical Attacks
- 25. DESIGN, EVOLUITION AND USE So, what do all of these languages have in common?
- 27. DSL Development New Language GPL Extension Existing Domain Notation (Informal) Formalization Formalized Language Reuse GPL incl. Expressions and TS Add/Embed DS-extensions Compatible notational style Reduce to GPL Analyze Domain to find Abstractions Define suitable, new notations Rely on existing behavioral paradigm Reuse standard expression language Interpret/Generate to one or more GPLs Use existing notation from domain Clean up and formalize Generate/Interpret Often import existing „models“
- 28. DSL Development New Language Analyze Domain to find Abstractions Define suitable, new notations Rely on existing behavioral paradigm Reuse standard expression language Interpret/Generate to one or more GPLs KernelF
- 29. DESIGN, EVOLUITION AND USE
- 30. Functional Features Functional, no state at its core. Purity + Effect Tracking The usual types, literals and op‘s Various Conditionals Functions and Blocks Error Handling Immutable Collections and higher-order functions Enums, tuples, records, all immutable Constraints on types and functions
- 31. Functional Stuff only: is this useful? A purely functional language only heats up the processor. -- Anonymous
- 32. Functional Features Functional, no state at its core. Purity + Effect Tracking The usual types, literals and op‘s Various Conditionals Functions and Blocks Error Handling Immutable Collections and higher-order functions Enums, tuples, records, all immutable Constraints on types and functions Boxes (like Clojure‘s ref) Transactional Memory State Machines Interactors Stateful Features
- 33. DESIGN, EVOLUITION AND USE
- 37. Tooling: REPL
- 38. Tooling: Test Case Generation
- 40. Tooling: Mutation Testing II
- 41. DESIGN, EVOLUITION AND USE
- 42. All languages shown in this talk are built with the open source JetBrains MPS language workbench.
- 43. + Refactorings, Find Usages, Syntax Coloring, Debugging, ...
- 44. DESIGN, EVOLUITION AND USE
- 46. Design Drivers Simplicity & Readability Extensibility Embeddability Robustness IDE Support Accessible to Non-Programmers Add new domain-specific language concepts if needed Refer to domain-specific context, remove/replace stuff that is not needed Make writing correct code as simple as possible A language without an IDE is irrelevant; Exploit MPS
- 47. DESIGN, EVOLUITION AND USE What we have.
- 48. Keyword-Rich Many first-class abstractions instead of the functional minimalism; better tool support.
- 49. Static Types Essential for good error messages and code completion for end users.
- 50. Type Inference Only the really necessary types have to be written down explicitly.
- 51. Numeric Types Few domains actually want int and real
- 52. Option Types ... to explicitly deal with null values
- 53. DESIGN, EVOLUITION AND USE What we have not.
- 54. No Generics ... for user-defined types, only built-in for collections.
- 55. No Algebraic Types Construction of sophisticated abstractions not necessary in DSLs; developed as langusage extensions.
- 56. No Exceptions Hard to implement efficiently on some platforms; but attempt types are an ok replacement.
- 57. No Function Comp & Monads Definition of sophisticated reusable functional abstractions not needed for DSL users.
- 58. No Reflection or Meta-Prog. All the „magic“ happens outside programs using the LWB.
- 59. DESIGN, EVOLUITION AND USE Enabling Extension and Embedding.
- 62. Concept Removals MPS Constraints can be used to effectively reduce the language.
- 63. Exchangeable Primitives PTF.create<Type>() Plus an extension infrastructure to contribute types.
- 64. Structure vs. Types Types, such as ListType or IRecordType can be used for custom language concepts.
- 65. Syntax Overriding New syntax can be defined for existing language concepts.
- 66. DESIGN, EVOLUITION AND USE Evolution.
- 67. number type We started with int and real, and quickly noticed that domain experts don‘t want this.
- 68. Transparent Options? val v : opt<T> = some(t) val v : opt<T> = t convenience Java generator
- 69. enums with Data
- 70. Records Didn‘t we say that structures are domain specific? Yes, but useful for prototyping.
- 71. ADTs + Patterns I did build an ADT language, but it‘s an extension. Problem with option and attempt.
- 72. State Isn‘t KernelF functional? Yes, but foundations for stateful extensions are very helpful.
- 73. DESIGN, EVOLUITION AND USE
- 74. DESIGN, EVOLUITION AND USE So, is this modeling or programming? ICMT
- 76. Programming vs. MD: What it can be
- 77. DESIGN, EVOLUITION AND USE It becomes hard to separate (modern) model-driven from programming.
- 78. DESIGN, EVOLUITION AND USE Wait, so you‘re at ICMT, you should at least talk a little bit about Transformation! ICMT
- 80. What good is all the abstraction if we cannot trust the translation to the implementation? System Architecture What good is all the abstraction if we cannot trust the translation to the implementation?
- 81. What good is all the abstraction if we cannot trust the translation to the implementation? System Architecture & Safety Standards Tools may introduce additional systematic errors if faulty. Safety standards require reliable mitigation of such errors. DO-178C EN50129 IEC62304 ISO26262
- 82. + Risk Analysis + Mitigations Modeling Architecture Model the Algo/System with the DSL and also model the tests/verification. Then translate both and execute on the level of the implementation.
- 83. Risk Analysis
- 84. Mitigations – Safe Modeling Architecture
- 85. Mitigations – Safe Modeling Architecture use redundant execution on two execution engines use different developers for the two trafos review a subset of the generated code clearly define and QA the DSL to use fuzzing on the tests ensure high coverage for the tests run the tests on the final device perform static analysis on the generated code perform penetration testing on the final system and use architectural safety mechanisms. only these specific to DSL use
- 87. XXXXXXX Toulouse
- 88. Incremental Graph Transformation Model Derived Model Incremental Analyser Interpreter Generator Incremental, Fast Acceptable Memory Overhead In MPS (client) and on the server (future) Convenient DSL for specifying the transformations
- 89. TAKEAWAYS
- 90. Modular Languages are useful and feasible based on modern LWB. Modeling == Programming Model Trafo == Compiler Construction The PL and MD communities should align more closely! DSLs & Model Trafo is not at odds with safety-critical systems. 1 2 3 4