Chapter 1. Learning to speak the Language of the Domain
1.1. The Problem Domain and the Solution Domain
1.1.1. Abstractions as the Core
1.2. Domain Modeling - Establishing a Common Vocabulary
1.3. Role of Abstractions in Domain Modeling
1.3.1. Minimalism publishes only what YOU promise
1.3.2. Distillation Keeps only what You need
1.3.3. Extensibility Helps Piecemeal Growth
1.3.3.1. Mixins - A Design Pattern for Extensibility
1.3.3.2. Mixins for extending MAP
1.3.3.3. Functional Extensibility
1.3.3.4. Extensibility can be Monkey Business too
1.3.4. Composability comes from Purity
1.3.4.1. Design Patterns for Composability
1.3.4.2. Back to Languages
1.3.4.3. Side-effects and Composability
1.3.4.4. Composability and Concurrency
1.4. Domain Specific Language (DSL) - It's all about Expressivity
1.4.1. Clarity of Intent
1.4.2. Expressivity's all about Well-Designed Abstractions
1.5. When do we need a DSL
1.5.1. The Advantages
1.5.2. The Disadvantages
1.6. DSL - What's in it for Non-Programmers?
1.7. Summary
1.8. Reference
Chapter 2. Domain Specific Languages in the Wild
2.1. A Motivating Example
2.1.1. Setting up the Common Vocabulary
2.1.2. The First Java Implementation
2.1.3. Externalize the Domain with XML
2.1.4. Groovy - a more Expressive Implementation Language
2.1.4.1. Executing the Groovy DSL
2.2. Classification of DSLs
2.2.1. Internal DSL Patterns - Commonality and Variability
2.2.1.1. Smart APIs, Fluent Interfaces
2.2.1.2. Code Generation through Runtime Meta-programming
2.2.1.3. Code Generation through Compile time Meta-programming
2.2.1.4. Explicit Abstract Syntax Tree manipulation
2.2.1.5. Pure Embedding of Typed Abstractions
2.2.2. External DSL Patterns - Commonality and Variability
2.2.2.1. Context driven String Manipulation
2.2.2.2. Transforming XML to Consumable Resource
2.2.2.3. Non-textual Representations
2.2.2.4. Mixing DSL with Embedded Foreign Code
2.2.2.5. Parser Combinator based DSL Design
2.3. Choosing DSL Implementations - Internal OR External
2.4. The Meta in the DSL
2.4.1. Runtime Meta-Programming in DSL Implementation
2.4.2. Compile time Meta-Programming in DSL Implementation
2.5. Lisp as the DSL
2.6. Summary
2.7. Reference
Chapter 3. DSL Driven Application Development
3.1. Exploring DSL Integration
3.2. Homogeneous Integration
3.2.1. Java 6 Scripting Engine
3.2.2. A DSL Wrapper
3.2.3. Language Specific Integration Features
3.2.4. Spring based Integration
3.3. Heterogeneous Integration with External DSLs
3.4. Handling Exceptions
3.5. Managing Performance
3.6. Summary
3.7. Reference
Chapter 4. Internal DSL Implementation Patterns
4.1 Building up your DSL Toolbox
4.2 Embedded DSL - Patterns in Meta-programming
4.2.1 Implicit Context and Smart APIs
4.2.2 Dynamic Decorators using Mixins
4.2.3 Hierarchical Structures using Builders
4.2.4 New Additions to your Toolbox
4.3 Embedded DSL - Patterns with Typed Abstractions
4.3.1 Higher Order Functions as Generic Abstractions
4.3.2 Explicit Type Constraints to model Domain logic
4.3.3 New Additions to your Toolbox
4.4 Generative DSL - Boilerplates for Runtime Generation
4.5 Generative DSL - one more tryst with Macros
4.6 Summary
4.7 References
4 comments:
Looks like it will be great!
To make the meaning of some of the section titles clearer, you might include a short paragraph describing the section.
In the shorter ToC on the Manning site, you include sections with examples of DSLs in Ruby, Scala, Clojure, etc. Do you still plan to include those examples?
Yes, that has not been written yet. Still being cooked up in the labs :). But, sure it will be there. I will update the ToC in my blog as and when chapters get out of the labs ..
As a starter with DSL, I want to share my difficulties to learn DSL as an average programmer. In the implementation of DSL, certain mathematical and pure Computer Science theoretical background is very helpful if I'm not very wrong. Is anything about these in any form in your title?
@gRoy():-
Not sure what you mean by computer science theoretical background. Internal DSL design is designing well-designed abstractions with the domain vocabulary. People also call "meta-linguistic abstractions", since it's a domain layer on top of an existing programming language. You can do that in Java or still better in languages that offer programming at a higher level of abstraction. Regarding external DSL, of course, if you want to design an elaborate language right from scratch, it's never an easy task. It requires lots of experience with language design. Is this what you are referring to ? In that case, I admit, it's not a layman's job and needs quite a bit of experience in the respective field.
Post a Comment