Practical DSL Design
                       London Groovy & Grails User Group
                               May 17th, 201...
Overview
  • What is a DSL?
  • Key Concepts
  • DSL Design
  • Implementing DSLs
  • Additional Considerations
          ...
Goals:
  • Understand:
    • What is a DSL
    • Where use one
    • Engineering considerations
  • NOT about syntax



Mo...
Division of Labor

    •       My Job:
        •      Present ideas


    •       Your Job:
        •      Discriminate, s...
About Me
   • Programmer: 50-80 projects/yr
   • Entrepreneur: profitable/practical
   • Research:
     • Domain Specific Mo...
What is a DSL?
      •      Specific to single domain - generally not
             Turing complete (excl. XSLT)
      •    ...
What is a DSL? - DSL vs. API
   • Subjective
   • Often facade to API
   • Focus on language nature
   • “Fluent” interfac...
What is a DSL? - Benefits
   • Expressive (clear intent, concise)
   • Separate business logic from code
   • Separate lif...
What is a DSL? - When Use?
      •       Frequently changing business rules
      •       Interactions with stakeholders
 ...
Key Concepts
   • Overview:
     • Vertical vs horizontal
     • Abstract vs Concrete
     • Projections
     • Three type...
Vertical vs. Horizontal
      •       Horizontal: technical domain
            •      SQL, CSS, GORM . . .
            •  ...
Abstract vs. Concrete
   • Abstract grammar       <person>
     • what say                <FirstName>Paul</FirstName>
    ...
Projections
   • Multiple projections
     • Textual
     • Spreadsheet
     • Visual
     • Form based



Monday, May 17,...
Three Broad Types of DSL
   • Internal (embedded)
   • External (parser)
   • Language workbench




Monday, May 17, 2010
Internal vs. External
   • Internal:              • External:
     • Easier to implement • Easier to evolve
     • Power o...
Top Down/Bottom Up
   • Bottom up:
     • Evolve from API (e.g.
                  Hibernate)
          •       Not very ex...
General Hints
   • Learn from DDD/UL:
     • Common, rigorous understanding
     • Driven by domain model
     • Involve t...
Implementing DSLs
   • API
   • Fluent interface
   • Reducing visual noise
   • Config file/XML/Json
   • Simple parser
   ...
API
   • Good starting point
   • Easy to evolve
   • Often readable enough . . .
     Event salesMeet = new event( startT...
Fluent interface
   • The start of DSLs
   • Language nature
   • Focus on sentence like syntax
                       Eve...
Reducing Visual Noise
   • Flexible and malleable
              syntax
      •       Metaprogramming
      •       AST tra...
Flexible and Malleable Syntax
   • Scripts
   • Optional typing
   • Native syntax constructs
     • (lists, maps)
   • Pa...
Metaprogramming
   • PoGo
   • Categories
   • Builders
   • Custom metaclass
   • ExpandoMetaClass


     © Guillaume Laf...
AST Transformations
      •       AST traversal
      •       Local transformations
      •       Global transformations
 ...
Outcome:
               event from 4.pm to 6.pm
                        .with “Joe” “Smith”
                        .and “...
Config File/XML/Json
   • Introduction to external DSLs
   • Easy to load/parse
   • Supports projections and tooling
    ...
Simple Parser
   • Delimiter directed translation
     • Regex or similar
     • Doesn’t support nesting
     • Only for s...
Nested Parser
   • Syntax directed translation
     • Grammar/parser
     • ANTLR




Monday, May 17, 2010
Additional Considerations
   • Testing
   • Evolution
   • Documentation
   • Error handling
   • IDE support



Monday, M...
Testing DSLs
   • Test domain model
   • Test fluent interface
              (expression builder)
            •      Can Co...
DSL Evolution
   • The problem: success!
   • Approaches:
     • No changes
     • Backwards compatibility
     • Versioni...
Documentation
   • Getting started guide
   • Samples
   • FAQs for common tasks
   • Language reference
   • Some debuggi...
Error Handling
   • Throw while process = easy
   • Meaningful messages hard




Monday, May 17, 2010
IDE Support
   • Syntax highlighting
   • Code completion
   • Static verification
   • IntelliJ helps . . .
   • If import...
Conclusions
   • It’s all about the domain
   • Evolve to DSLs
   • API to internal . . .
   • . . . external if required
...
Resources

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

   DSM:
   JP Tolvanen: http://www.meta...
Resources (2)
  DSLs:
  Martin Fowler: http://martinfowler.com/dslwip/

  Groovy DSLs:
  Google - Guillaume Laforge, Paul ...
The End!
  • http://gettinggroovy.com
  • Email: peter@pbell.com
  • Twitter: peterbell




Monday, May 17, 2010
Upcoming SlideShare
Loading in …5
×

GGUG:Practical DSL Design

1,344
-1

Published on

What are some practical uses for Domain Specific Languages (DSL)? And how do you go about designing DSLs, implementing them in Groovy, creating tests for your models and evolving the structure of the languages over time?

In this fast paced session, Peter Bell will examine a real world Groovy DSL, how it was designed and implemented, the testing strategies employed and the options for evolving the structure (grammar) of the DSL.

If you've built DSLs but want to go further, or if you've still not figured out how a DSL might help you to build better, more maintainable apps more quickly and easily, come along and learn more about creating practical, maintainable DSLs for your projects.

Just a thought . . . If you are interested in this talk you might also be interested in Core Gradle: Gradle, a Build System for Java Workshop and Graeme Rocher's Groovy and Grails Workshop

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,344
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
79
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

GGUG:Practical DSL Design

  1. 1. Practical DSL Design London Groovy & Grails User Group May 17th, 2010 Peter Bell CEO/CTO SystemsForge Monday, May 17, 2010
  2. 2. Overview • What is a DSL? • Key Concepts • DSL Design • Implementing DSLs • Additional Considerations • Testing, evolution, documentation, error handling , IDE support Monday, May 17, 2010
  3. 3. Goals: • Understand: • What is a DSL • Where use one • Engineering considerations • NOT about syntax Monday, May 17, 2010
  4. 4. Division of Labor • My Job: • Present ideas • Your Job: • Discriminate, select, adapt, experiment Monday, May 17, 2010
  5. 5. 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 . . . Monday, May 17, 2010
  6. 6. 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 Monday, May 17, 2010
  7. 7. What is a DSL? - DSL vs. API • Subjective • Often facade to API • Focus on language nature • “Fluent” interface API: new event( startTime: "16:00", endTime: "18:00" ) DSL: new event.from 4.pm, to: 6.pm Monday, May 17, 2010
  8. 8. What is a DSL? - Benefits • Expressive (clear intent, concise) • Separate business logic from code • Separate lifecycle • SME readable (not writable) Monday, May 17, 2010
  9. 9. 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 Monday, May 17, 2010
  10. 10. Key Concepts • Overview: • Vertical vs horizontal • Abstract vs Concrete • Projections • Three types of DSL • Internal vs. External Monday, May 17, 2010
  11. 11. 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 Monday, May 17, 2010
  12. 12. Abstract vs. Concrete • Abstract grammar <person> • what say <FirstName>Paul</FirstName> <LastName>King</LastName> • Concrete syntax </person> • how say new person( firstName: "Paul", lastName: "King" ) person called “Paul “, “ King “ Paul King Monday, May 17, 2010
  13. 13. Projections • Multiple projections • Textual • Spreadsheet • Visual • Form based Monday, May 17, 2010
  14. 14. Three Broad Types of DSL • Internal (embedded) • External (parser) • Language workbench Monday, May 17, 2010
  15. 15. Internal vs. External • Internal: • External: • Easier to implement • Easier to evolve • Power of GPL: • End user writable (forms)? • Loops • Projectional: • Math • Forms • Conditionals . . . • Visual • Refactor to external • Spreadsheet Monday, May 17, 2010
  16. 16. 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 Monday, May 17, 2010
  17. 17. 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 Monday, May 17, 2010
  18. 18. Implementing DSLs • API • Fluent interface • Reducing visual noise • Config file/XML/Json • Simple parser • Nested parser Monday, May 17, 2010
  19. 19. 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 ) Monday, May 17, 2010
  20. 20. 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” ) Monday, May 17, 2010
  21. 21. Reducing Visual Noise • Flexible and malleable syntax • Metaprogramming • AST transformations © Guillaume Laforge Monday, May 17, 2010
  22. 22. Flexible and Malleable Syntax • Scripts • Optional typing • Native syntax constructs • (lists, maps) • Parentheses/semi omission • Named arguments • Operator overloading • Closures © Guillaume Laforge Monday, May 17, 2010
  23. 23. Metaprogramming • PoGo • Categories • Builders • Custom metaclass • ExpandoMetaClass © Guillaume Laforge Monday, May 17, 2010
  24. 24. AST Transformations • AST traversal • Local transformations • Global transformations • Hooks into ANTLR © Guillaume Laforge Monday, May 17, 2010
  25. 25. Outcome: event from 4.pm to 6.pm .with “Joe” “Smith” .and “Fred” “Jones” © Guillaume Laforge Monday, May 17, 2010
  26. 26. 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> Monday, May 17, 2010
  27. 27. Simple Parser • Delimiter directed translation • Regex or similar • Doesn’t support nesting • Only for simplest languages Monday, May 17, 2010
  28. 28. Nested Parser • Syntax directed translation • Grammar/parser • ANTLR Monday, May 17, 2010
  29. 29. Additional Considerations • Testing • Evolution • Documentation • Error handling • IDE support Monday, May 17, 2010
  30. 30. Testing DSLs • Test domain model • Test fluent interface (expression builder) • Can Compile • Scenarios • Orthogonal test DSLs Monday, May 17, 2010
  31. 31. DSL Evolution • The problem: success! • Approaches: • No changes • Backwards compatibility • Versioning • Model migrations Monday, May 17, 2010
  32. 32. 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 Monday, May 17, 2010
  33. 33. Error Handling • Throw while process = easy • Meaningful messages hard Monday, May 17, 2010
  34. 34. IDE Support • Syntax highlighting • Code completion • Static verification • IntelliJ helps . . . • If important, consider Xtext/EMF Monday, May 17, 2010
  35. 35. 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 Monday, May 17, 2010
  36. 36. Resources History: http://www.faqs.org/docs/artu/minilanguageschapter.html DSM: JP Tolvanen: http://www.metacase.com/blogs/jpt/blogView Steve Kelly: http://www.metacase.com/blogs/stevek/blogView Markus Voelter: http://www.voelter.de/ DDD: http://domaindrivendesign.org/ Monday, May 17, 2010
  37. 37. 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/Tolvanen Generative Programming - Czarnecki/Eisenecker Domain Driven Design - Evans Monday, May 17, 2010
  38. 38. The End! • http://gettinggroovy.com • Email: peter@pbell.com • Twitter: peterbell Monday, May 17, 2010
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×