formal semantics
play

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


  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 on Domain-Specific Language Design and Implementation in Portland, Oregon, October 20, 2014

  2. The great work of this community makes Language Implementation easier and easier

  3. so more and more programmers build their own custom DSL

  4. and become programmers and language designers at the same time

  5. Language Design is still HARD

  6. How can a programmer/ language designer learn to design languages that are elegant and usable?

  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

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

  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.

  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 .

  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.

  12. name Bound & Binding Occurrences problem How to structure names? solution Distinguish bound and binding occurrences of names. Each bound occurrences refers to a binding occurrence. effects You can reason about the naming structure of a program in terms of „this name here is bound there“

  13. name Bound & Binding Occurrences Lexical Scoping name problem How to structure names? problem Which bound occurrence refers to solution Distinguish bound and binding which binding occurrence? occurrences of names. Each bound solution occurrences refers to a binding All bound occurrences in a occurrence. continuous region of the source file bind to the same binding effects You can reason about the naming occurrence. structure of a program in terms of effects „this name here is bound there“ You can reason about the binding structure statically.

  14. name Bound & Binding Occurrences Lexical Scoping name problem How to structure names? name Domain-Specific Scoping problem Which bound occurrence refers to solution Distinguish bound and binding which binding occurrence? problem occurrences of names. Each bound Which bound occurrence refers to solution occurrences refers to a binding which binding occurrence? All bound occurrences in a occurrence. continuous region of the source file solution Use domain-specific criteria to bind to the same binding effects You can reason about the naming match bound to binding occurrence. structure of a program in terms of occurrences. effects „this name here is bound there“ You can reason about the binding effects Your binding structure supports structure statically. your domain integration.

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

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

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

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

  19. name Type Structure problem How to structure the primitives? solution Structure your language design around the available types of values. Think of the primitives as the interfaces of the types. effects Easier to not forget primitives. Structuring principle also for documentation.

  20. name Type Structure name Constructor problem How to structure the primitives? problem Which operations for a type? solution Structure your language design solution around the available types of Provide constructors for making values. Think of the primitives as new values of a type. the interfaces of the types. effects User programs can create values of effects Easier to not forget primitives. the type. Structuring principle also for documentation.

  21. name Type Structure name Constructor problem How to structure the primitives? Destructor name problem Which operations for a type? solution Structure your language design problem Which operations for a type? solution around the available types of Provide constructors for making values. Think of the primitives as solution new values of a type. Provide destructors for getting the interfaces of the types. information out of values of a type. effects User programs can create values of effects Easier to not forget primitives. effects the type. User programs can use values of Structuring principle also for the type. documentation.

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

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

  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.

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend