The document discusses different aspects of designing domain-specific languages (DSLs), including expressivity, linguistic abstraction, platform influence, coverage, and static semantics validation. It provides examples of using conditional statements vs decision tables for expressivity, introducing new concepts like "connected ports" for linguistic abstraction, supporting time units like days that may not fit in integer types due to platform constraints, adding special statements to handle timed events, and designing product inheritance with override and validation rules.

1. Design dimensions

2. Expressivity
decision table vs.
conditional statements
if (i<0 AND j<0) { a = -10 ;}
if (i<0 AND j==0) { a = 1 ;}
if (i<0 AND j>0) { a = 10 ;}
if (i==0 AND j<0) { a = -20 ;}
if (i==0 AND j==0) { a = 2 ;}
if (i==0 AND j>0) { a = 20 ;}
if (i>0 AND j<0) { a = -30 ;}
if (i>0 AND j==0) { a = 3 ;}
if (i>0 AND j>0) { a = 30 ;}

3. Linguistic abstraction
by introducing a new abstract for that concept
modelling of by using existing abstractions
without linguistic abstraction
a domain concept
concepts of domain D first-class members of language for D
can be uniquely identified in a program
their structure and semantics are well-defined
analyse the program
“reverse-engineer” the semantics
with linguistic abstraction rely on language user to use the correct abstraction

4. Linguistic abstraction “Optional” elements
port connected
IDE
unconnected
errorinvoking an operation on an unconnected port
use if-statements check whether port is connected
if (isConnected(p)) {p.doSomething();}
any Boolean expression
can be used here if (isConnected(p) OR true) {p.doSomething();}
impossible to check statically
compare in Java:
if (obj != null) obj.x();
introduce a new language concept to check directly whether a port is connected
with port p {p.doSomething();}
check that invocation is done in with-port-statement referencing the same port
compare with Groovy: obj?.x() – null-safe
translates to “if”, but does not
use Boolean expressions

5. Platform influence
mbeddr doesn’t support dynamically growing lists
because it’s hard to implement them efficiently in embedded software
DSL with time periods users need to define time periods in cooling algorithms
no single unit could fit all necessary values into int types
seconds
days can’t express shorter periods without using fractions or floats
allow for expressing units directly
wait 3 wait 259200 3 days
wait 3 wait 3/86400 3 seconds
wait 3 sec wait 1 month
days or months wouldn’t fit into available ints int8

6. Coverage
add special statement to the language
DSL
can be done manually
perform ... after t
some statements should be run after a specified time elapsed
using events and times

7. Static semantics (validation)
validation of sub-product reports error
insurance product
if rule in base plan is removed/renamed
alternative design
can inherit another insurance product
“base” product – cf.
“super class” in Java
payment calculation rule can override a rule in the base product
should be marked with “overrides” modifier
a rule overrides another rule if they have the same signature
name and parameters
users more prone to do something they didn’t intend
a user might not want to override a rule from the base plan
but still does because the signatures happen to be the same
Java (final methods)
vs.
C# (override methods)
Delphi: overload for
methods with same names