Summary Design Guidelines for Domain Specific Languages arxiv.org
7,037 words - PDF document - View PDF document
One Line
Designing a DSL is complex and existing tools lack guidance, but guidelines such as identifying uses, simplicity, modularity, and project-specific requirements can help navigate the process.
Slides
Slide Presentation (9 slides)
Key Points
- Designing a new domain specific language (DSL) can be complex and time-consuming.
- Existing tool support for DSL design focuses on technical aspects but lacks support for enforcing principles for good language design.
- Guidelines for designing DSLs should be based on experience in developing languages and existing guidelines for general purpose and modeling languages.
- Guidelines for designing DSLs should focus on identifying the purpose of the language, reflecting only necessary domain concepts, keeping the language simple, adopting existing notations used by domain experts, aligning concrete and abstract syntax, and considering project-specific requirements and constraints.
- The decision to reuse existing languages or implement a new one is an important consideration in DSL design.
Summaries
19 word summary
Designing a DSL is complex; existing tool support lacks guidance. Guidelines include identifying uses, simplicity, modularity, and project-specific requirements.
52 word summary
Designing a domain specific language (DSL) is complex. Existing tool support lacks guidance. Guidelines for DSL design include identifying uses, determining necessary concepts, simplicity, avoiding redundancy, and efficient elements. Adopt existing notations and use syntactic sugar sparingly. Align abstract and concrete syntax, support modularity and information hiding. Consider project-specific requirements and constraints.
221 word summary
Designing a domain specific language (DSL) is a complex task. Existing tool support lacks guidance for good language design. The authors investigate guidelines for DSL design, drawing on their experience and existing guidelines for general purpose and modeling languages.
Guidelines for the purpose of the language include identifying its uses early on, such as documentation, code generation, testing, verification, analysis, or simulation. This helps determine the necessary concepts and features.
Design guidelines focus on reflecting only necessary domain concepts in the language, keeping it simple, avoiding unnecessary generality, limiting language elements, avoiding redundancy, and inefficient elements.
The concrete syntax should adopt existing notations used by domain experts when possible. Descriptive notations and distinguishable representations contribute to understandability. Syntactic sugar can improve readability but should not be overused. Comments should be permitted, and organizational structures provided.
The abstract syntax should align closely with the concrete syntax for automated processing. Good layout should not affect meaning, and modularity should enable decomposition into small pieces. Interfaces should support modular development and information hiding.
Some guidelines may contradict or need different weighting depending on project settings, size, usage, and costs. Reusing existing languages or implementing new ones is an important consideration.
These guidelines are a basis for DSL design but may need to be extended or updated. Project-specific requirements and constraints should also be considered.
355 word summary
Designing a new domain specific language (DSL) can be a complex and time-consuming task. Existing tool support focuses on technical aspects but lacks support for enforcing principles for good language design. In this paper, the authors investigate guidelines for designing DSLs, based on their experience in developing languages and existing guidelines for general purpose and modeling languages.
The first set of guidelines focus on the purpose of the language. It is important to identify the uses of the language early on, such as documentation, code generation, testing, verification, analysis, or simulation. This identification helps determine the concepts and features that the language should include.
The next set of guidelines address the design of the language itself. It is important to reflect only the necessary domain concepts in the language and to keep it simple. Unnecessary generality should be avoided, and the number of language elements should be limited. Redundancy should also be avoided, as well as inefficient language elements.
The concrete syntax of the language should adopt existing notations used by domain experts whenever possible. Descriptive notations and distinguishable representations of language elements contribute to understandability. Syntactic sugar can be used appropriately to improve readability, but it should not be overused. Comments should be permitted to explain design decisions, and organizational structures should be provided for models.
The abstract syntax of the language should align closely with the concrete syntax to ease automated processing and presentation. A good layout of the model should not affect its meaning, and modularity should be enabled through decomposition into small pieces. Interfaces should be introduced to support modular development and information hiding.
The authors acknowledge that some guidelines may contradict each other or need to be weighted differently depending on project settings, size of language instances, intended usage, and costs. The decision to reuse existing languages or implement a new one is also an important consideration.
In conclusion, these guidelines provide a basis for designing DSLs, but they are not exhaustive and may need to be extended or updated over time. It is also important to consider the specific requirements and constraints of each project when applying these guidelines.