DESIGN, EVOLUTION AND USE

Size: px

Start display at page:

Download "DESIGN, EVOLUTION AND USE"

Clyde Campbell
6 years ago
Views:

1 DESIGN, EVOLUTION AND USE of KernelF Markus Völter

2 Check out the paper! /pub/kernelf-icmt.pdf

3 EXAMPLE 1 Healthcare 1

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.

6 Some Language Impressions I

7 Some Language Impressions II

8 Some Language Impressions III

9 Execution What Architecture good is all the abstraction if we cannot trust the translation to the implementation?

10 DESIGN, EVOLUITION AND USE

11 EXAMPLE 2 Salary + Tax 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

18 EXAMPLE 3 Smart Contracts 3

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.

20 Declarative Description

21 Execution and Test

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?

26 KernelF, the Language 4

27 DSL Development GPL Extension Reuse GPL incl. Expressions and TS Add/Embed DS-extensions Compatible notational style Reduce to GPL 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 Formalization Use existing notation from domain Clean up and formalize Generate/Interpret Often import existing models Existing Domain Notation (Informal) Formalized Language

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 Stateful Features Boxes (like Clojure s ref) Transactional Memory State Machines Interactors Immutable Collections and higher-order functions Enums, tuples, records, all immutable Constraints on types and functions

33 DESIGN, EVOLUITION AND USE

34 Tooling: Live Execution

35 Tooling: Coverage

36 Tooling: Debugging

37 Tooling: REPL

38 Tooling: Test Case Generation

39 Tooling: Mutation Testing I

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

45 5 Design Decisions and Evolution

46 Design Drivers Simplicity & Readability Accessible to Non-Programmers Extensibility Add new domain-specific language concepts if needed Embeddability Refer to domain-specific context, remove/replace stuff that is not needed Robustness Make writing correct code as simple as possible IDE Support 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.

60 Modular Implementation

61 Abstract Concepts Expression Type IToplevelContent IDotTarget

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) convenience Java generator val v : opt<t> = t

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 ICMT So, is this modeling or programming?

75 6 Modeling & Programming

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 ICMT Wait, so you re at ICMT, you should at least talk a little bit about Transformation!

79 Execution and Safety 7

80 What System good Architecture is all the abstraction if we cannot trust the translation to the implementation? What good is all the abstraction if we cannot trust the translation to the implementation?

81 What System good Architecture is all the abstraction & Safety if Standards we cannot trust the translation to the implementation? Tools may introduce additional systematic errors if faulty. Safety standards require reliable mitigation of such errors. DO-178C EN50129 IEC62304 ISO26262

82 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. + Risk Analysis + Mitigations

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 only these specific to DSL use 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.

86 Successfully passed FDA Pre-Submission

87 Toulouse XXXXXXX

88 Incremental Graph Transformation Analyser Model Incremental Derived Model 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.

Declarative. Contracts

Declarative. Contracts Declarative Smart Contracts Markus Völter voelter@acm.org www.voelter.de @markusvoelter 1 Context SMART An actual contract, executed automatically. CONTRACT Any Turing Complete Program running on a Blockchain.