Formal Semantics as a Language Designer's Toolbox Paolo G. - - PowerPoint PPT Presentation

formal semantics
SMART_READER_LITE
LIVE PREVIEW

Formal Semantics as a Language Designer's Toolbox Paolo G. - - PowerPoint PPT Presentation

Formal Semantics as a Language Designer's Toolbox Paolo G. Giarrusso Klaus Ostermann Tillmann Rendel University of Marburg University of Tbingen Eric Walkingshaw University of Marburg Oregon State University Presentation by


slide-1
SLIDE 1

Formal Semantics

as a Language Designer's

Toolbox

Paolo G. Giarrusso · Klaus Ostermann · Tillmann Rendel University of Marburg · University of Tübingen Eric Walkingshaw University of Marburg · Oregon State University

Presentation by Tillmann Rendel at the Second International Workshop

  • n Domain-Specific Language Design and Implementation

in Portland, Oregon, October 20, 2014

slide-2
SLIDE 2

The great work

  • f this community makes

Language Implementation

easier and easier

slide-3
SLIDE 3

so more and more

programmers

build their own custom

DSL

slide-4
SLIDE 4

and become

programmers

and

language designers

at the same time

slide-5
SLIDE 5

Language Design

is still

HARD

slide-6
SLIDE 6

How can a

programmer/ language designer

learn to design languages that are

elegant and usable?

slide-7
SLIDE 7

Formal Semantics

  • Semanticists know a lot about languages

(it's their job)

  • Semanticists know a lot about elegance

(they are mathematicians)

  • Mathematical elegance has pragmatic advantages

Elegant = powerful and simple, less to learn

slide-8
SLIDE 8

Can formal semantics guide a programmer/language designer towards an elegant and usable design?

slide-9
SLIDE 9

Problem 1

  • Problem: Formal semantics is a lot of work.
  • Proposed Solution: Don't actually formalize the

semantics, just let the insights of formal semantics guide your design process.

slide-10
SLIDE 10

Problem 2

  • Problem: The language of the semanticists is not

understandable to the working programmer/language designers

  • Proposed Solution: Package the insights from

formal semantics as language design patterns.

slide-11
SLIDE 11

Language Design Patterns

  • Patterns work for software design,

we want to adapt them for language design

  • Use terms that make sense to the working

programmer/language designer

  • Not in scope: language implementation patterns
  • Not in scope: designing perfect languages
  • In scope: language design patterns for reasonably

elegant, usable languages.

slide-12
SLIDE 12

Bound & Binding Occurrences How to structure names? Distinguish bound and binding

  • ccurrences of names. Each bound
  • ccurrences refers to a binding
  • ccurrence.

You can reason about the naming structure of a program in terms of „this name here is bound there“ name problem solution effects

slide-13
SLIDE 13

Bound & Binding Occurrences How to structure names? Distinguish bound and binding

  • ccurrences of names. Each bound
  • ccurrences refers to a binding
  • ccurrence.

You can reason about the naming structure of a program in terms of „this name here is bound there“ name problem solution effects Lexical Scoping Which bound occurrence refers to which binding occurrence? All bound occurrences in a continuous region of the source file bind to the same binding

  • ccurrence.

You can reason about the binding structure statically. name problem solution effects

slide-14
SLIDE 14

Bound & Binding Occurrences How to structure names? Distinguish bound and binding

  • ccurrences of names. Each bound
  • ccurrences refers to a binding
  • ccurrence.

You can reason about the naming structure of a program in terms of „this name here is bound there“ name problem solution effects Lexical Scoping Which bound occurrence refers to which binding occurrence? All bound occurrences in a continuous region of the source file bind to the same binding

  • ccurrence.

You can reason about the binding structure statically. name problem solution effects Domain-Specific Scoping Which bound occurrence refers to which binding occurrence? Use domain-specific criteria to match bound to binding

  • ccurrences.

Your binding structure supports your domain integration. name problem solution effects

slide-15
SLIDE 15

Meaning How to specify the semantics? Map every program to its meaning. Allows to identify programs that mean the same but work differently internally. name problem solution effects

slide-16
SLIDE 16

Meaning How to specify the semantics? Map every program to its meaning. Allows to identify programs that mean the same but work differently internally. name problem solution effects Simple Meaning How to structure the meaning? Choose the simplest thing that works. Carefully choosing the meaning helps you focus your design on your domain. name problem solution effects

slide-17
SLIDE 17

Meaning How to specify the semantics? Map every program to its meaning. Allows to identify programs that mean the same but work differently internally. name problem solution effects Simple Meaning How to structure the meaning? Choose the simplest thing that works. Carefully choosing the meaning helps you focus your design on your domain. name problem solution effects Recursive Meaning How to define the meaning mapping? Map each phrase of the program to its meaning. You can explain what a part of a program means. name problem solution effects

slide-18
SLIDE 18

Meaning How to specify the semantics? Map every program to its meaning. Allows to identify programs that mean the same but work differently internally. name problem solution effects Simple Meaning How to structure the meaning? Choose the simplest thing that works. Carefully choosing the meaning helps you focus your design on your domain. name problem solution effects Recursive Meaning How to define the meaning mapping? Map each phrase of the program to its meaning. You can explain what a part of a program means. name problem solution effects Compositional Meaning How to define the meaning mapping? Define the meaning of a phrase in terms of the meaning of its subphrases. The meaning of a phrase is the phrase's interface. Allow code moving without changing meaning. name problem solution effects

slide-19
SLIDE 19

Type Structure How to structure the primitives? Structure your language design around the available types of

  • values. Think of the primitives as

the interfaces of the types. Easier to not forget primitives. Structuring principle also for documentation. name problem solution effects

slide-20
SLIDE 20

Type Structure How to structure the primitives? Structure your language design around the available types of

  • values. Think of the primitives as

the interfaces of the types. Easier to not forget primitives. Structuring principle also for documentation. name problem solution effects Constructor Which operations for a type? Provide constructors for making new values of a type. User programs can create values of the type. name problem solution effects

slide-21
SLIDE 21

Type Structure How to structure the primitives? Structure your language design around the available types of

  • values. Think of the primitives as

the interfaces of the types. Easier to not forget primitives. Structuring principle also for documentation. name problem solution effects Constructor Which operations for a type? Provide constructors for making new values of a type. User programs can create values of the type. name problem solution effects Destructor Which operations for a type? Provide destructors for getting information out of values of a type. User programs can use values of the type. name problem solution effects

slide-22
SLIDE 22

Type Structure How to structure the primitives? Structure your language design around the available types of

  • values. Think of the primitives as

the interfaces of the types. Easier to not forget primitives. Structuring principle also for documentation. name problem solution effects Constructor Which operations for a type? Provide constructors for making new values of a type. User programs can create values of the type. name problem solution effects Destructor Which operations for a type? Provide destructors for getting information out of values of a type. User programs can use values of the type. name problem solution effects Information Preservation How to balance constructors and destructors? Provide enough destructors to get all information out of an constructed value. Provide enough constructors to recreate a destructed value. No identity and no secrets. Name problem solution effects

slide-23
SLIDE 23

Language Design Patterns ...

  • guide the design process

(„think of all constructors“)

  • structure the design

(„separate constructors and destructors“)

  • highlight design choices

(„which kind of scoping is appropriate?“)

  • explain effects („user programs can ...“)
  • interact („if a compositional meaning is a phrase's

interface, a simple meaning is a better interface“)

slide-24
SLIDE 24

Conclusion

  • We can try to phrase insights from formal

semantics as language design patterns

  • The language design patterns should use terms

that make sense to the working programmer/language designer

  • Future Work:

Collect language design patterns and distill them into a coherent pattern language.