KernelF is a functional language built on top of MPS. It is designed to be highly extensible and embeddable in order to support its use at the core of domain-specific languages, realising an approach we sometimes call Funclerative Programming. 'Funclerative' is of course a mash-up of 'functional' and 'declarative' and refers to the idea of using functional programming in the small, and declarative language constructs for the larger-scale, often domain-specific, structures in a program. We have used KernelF in a wide range of languages including health and medicine, insurance contract definition, security analysis, salary calculations, smart contracts and language-definition. In this keynote, I illustrate the evolution of KernelF over the last two years. I discuss requirements on the language, and how those drove design decisions. I showcase a couple of the DSLs we built on top of KernelF to explain how MPS was used to enable the necessary language modularity. I demonstrate how we have integrated the Z3 solver to verify some aspects of programs. I present the architecture we have used to use KernelF-based DSLs in safety-critical environments. I close the keynote with an outlook on how KernelF might evolve in the future, and point out a few challenges for which we don't yet have good solutions.

1. DESIGN, EVOLUTION AND USE
Markus Völter
voelter@acm.org
www.voelter.de
@markusvoelter
of
KernelF

2. http://voelter.de/data
/pub/kernelf-icmt.pdf
Check out the paper!

3. 1
Healthcare
EXAMPLE 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. 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

18. 3
Smart Contracts
EXAMPLE 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. 4
KernelF, the Language

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

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
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.

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)
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

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

79. 7
Execution and Safety

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

86. http://voelter.de/data/pub/MPS-in-Safety-1.0.pdf
Successfully
passed FDA
Pre-Submission

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