practical dsl design - wordpress.com › 2010 › 05 › 2010-05-londo… · practical dsl design...

Practical DSL Design

London Groovy & Grails User GroupMay 17th, 2010

Peter BellCEO/CTO SystemsForge

Monday, May 17, 2010

Overview• What is a DSL?

• Key Concepts

• DSL Design

• Implementing DSLs

• Additional Considerations

• Testing, evolution, documentation, error handling , IDE support


Goals:• Understand:

• What is a DSL

• Where use one

• Engineering considerations

• NOT about syntax


Division of Labor

• My Job:

• Present ideas

• Your Job:

• Discriminate, select, adapt, experiment


About Me• Programmer: 50-80 projects/yr

• Entrepreneur: profitable/practical

• Research:

• Domain Specific Modeling/DSLs

• Software Product Lines

• Writer: GroovyMag, InfoQ, IEEE Software, JSMag, Methods & Tools, Fusion Authority, Flex Authority . . .

• Presenter: ooPSLA, Code Generation, BCS SPA . . .


What is a DSL?• Specific to single domain - generally not

Turing complete (excl. XSLT)

• More expressive than GPL within the domain

• Executable

• Examples: SQL, CSS, Regex, PC configurator, document workflow rules


• Subjective

• Often facade to API

• Focus on language nature

• “Fluent” interface

What is a DSL? - DSL vs. API

API: new event( startTime: "16:00", endTime: "18:00" )

DSL: new event.from 4.pm, to: 6.pm


What is a DSL? - Benefits• Expressive (clear intent, concise)

• Separate business logic from code

• Separate lifecycle

• SME readable (not writable)


What is a DSL? - When Use?

• Frequently changing business rules

• Interactions with stakeholders

• Relatively well understood domain

• Typical use cases:

• Product family

• Platform based development

• Configuration

• Business rule definitions


Key Concepts• Overview:

• Vertical vs horizontal

• Abstract vs Concrete

• Projections

• Three types of DSL

• Internal vs. External


Vertical vs. Horizontal• Horizontal: technical domain

• SQL, CSS, GORM . . .

• More maintainable/readable code

• Good enough is good enough

• Vertical: business domain

• Insurance, PC configurator . . .

• Share “code” with SME’s

• Readability is key


Abstract vs. Concrete• Abstract grammar

• what say

• Concrete syntax

• how say

<person> <FirstName>Paul</FirstName>

<LastName>King</LastName></person>

new person( firstName: "Paul", lastName: "King" )

person called “Paul “, “ King “

Paul King


Projections• Multiple projections

• Textual

• Spreadsheet

• Visual

• Form based


Three Broad Types of DSL• Internal (embedded)

• External (parser)

• Language workbench


Internal vs. External• Internal:

• Easier to implement

• Power of GPL:

• Loops

• Math

• Conditionals . . .

• Refactor to external

• External:

• Easier to evolve

• End user writable (forms)?

• Projectional:

• Forms

• Visual

• Spreadsheet


Top Down/Bottom Up• Bottom up:

• Evolve from API (e.g. Hibernate)

• Not very expressive, but quick starting point

• Top down:

• Sketch out UL with stakeholders

• Generally better language


General Hints• Learn from DDD/UL:

• Common, rigorous understanding

• Driven by domain model

• Involve to SME’s

• Lots of little languages (e.g. Grails)

• Bounded contexts

• Risk:

• DSL eventually becomes badly designed GPL

• Think: Ant


Implementing DSLs• API

• Fluent interface

• Reducing visual noise

• Config file/XML/Json

• Simple parser

• Nested parser


API• Good starting point

• Easy to evolve

• Often readable enough . . .

Event salesMeet = new event( startTime: "16:00", endTime: "18:00" )Participant Joe = new Participant( firstName: “Joe”, lastName: “Smith” )Participant Fred = new Participant( firstName: “Fred”, lastName: “Jones” )salesMeet.addParticipant( Joe )salesMeet.addParticipant( Fred )


Fluent interface• The start of DSLs

• Language nature

• Focus on sentence like syntax

Event salesMeet = new event( from: 4.pm, to: 6.pm ).with( “Joe”, “Smith” ).and( “Fred”, “Jones” )


Reducing Visual Noise• Flexible and malleable

syntax

• Metaprogramming

• AST transformations

© Guillaume Laforge


Flexible and Malleable Syntax• Scripts

• Optional typing

• Native syntax constructs

• (lists, maps)

• Parentheses/semi omission

• Named arguments

• Operator overloading

• Closures



Metaprogramming• PoGo

• Categories

• Builders

• Custom metaclass

• ExpandoMetaClass



AST Transformations


• AST traversal

• Local transformations

• Global transformations

• Hooks into ANTLR


Outcome:


event from 4.pm to 6.pm .with “Joe” “Smith” .and “Fred” “Jones”


Config File/XML/Json• Introduction to external DSLs

• Easy to load/parse

• Supports projections and tooling

<events><event startTime=”16:00” endTime=”18:00”>

<participants><participant firstname=”Joe” lastName=”Smith” /><participant firstname=”Joe” lastName=”Smith” />

</participants></event>

<events>


Simple Parser• Delimiter directed translation

• Regex or similar

• Doesn’t support nesting

• Only for simplest languages


Nested Parser• Syntax directed translation

• Grammar/parser

• ANTLR


Additional Considerations• Testing

• Evolution

• Documentation

• Error handling

• IDE support


Testing DSLs• Test domain model

• Test fluent interface (expression builder)

• Can Compile

• Scenarios

• Orthogonal test DSLs


DSL Evolution• The problem: success!

• Approaches:

• No changes

• Backwards compatibility

• Versioning

• Model migrations


Documentation• Getting started guide

• Samples

• FAQs for common tasks

• Language reference

• Some debugging suggestions

• Not more than API requires

• Source/regression tests help but aren't enough


Error Handling• Throw while process = easy

• Meaningful messages hard


IDE Support• Syntax highlighting

• Code completion

• Static verification

• IntelliJ helps . . .

• If important, consider Xtext/EMF


Conclusions• It’s all about the domain

• Evolve to DSLs

• API to internal . . .

• . . . external if required

• Check Guillaume’s preso for syntax

• Think about additional considerations from day 1


Resources

History:http://www.faqs.org/docs/artu/minilanguageschapter.html

DSM:JP Tolvanen: http://www.metacase.com/blogs/jpt/blogViewSteve Kelly: http://www.metacase.com/blogs/stevek/blogViewMarkus Voelter: http://www.voelter.de/

DDD:http://domaindrivendesign.org/


http://www.faqs.org/docs/artu/minilanguageschapter.html

http://www.faqs.org/docs/artu/minilanguageschapter.html

http://www.metacase.com/blogs/jpt/blogView

http://www.metacase.com/blogs/jpt/blogView

http://www.metacase.com/blogs/stevek/blogView

http://www.metacase.com/blogs/stevek/blogView

http://www.voelter.de

http://www.voelter.de

http://domaindrivendesign.org

http://domaindrivendesign.org

Resources (2)DSLs:Martin Fowler: http://martinfowler.com/dslwip/

Groovy DSLs:Google - Guillaume Laforge, Paul King, Hamlet D’Arcy, Venkat Subramaniam, Neil Ford

DSL Evolution:http://www.infoq.com/articles/dsl-evolution

Books:Domain Specific Modeling - Kelly/TolvanenGenerative Programming - Czarnecki/EiseneckerDomain Driven Design - Evans


http://martinfowler.com/dslwip/

http://martinfowler.com/dslwip/

http://www.infoq.com/articles/dsl-evolution

http://www.infoq.com/articles/dsl-evolution

The End!• http://gettinggroovy.com

• Email: [email protected]

• Twitter: peterbell


http://gettinggroovy.wordpress.com






practical dsl design - wordpress.com › 2010 › 05 › 2010-05-londo… · practical dsl design...

Documents