About this blog…

Language composition is one of the desirable aspects of Software Language Engineering to enable reusability of the existing languages. These days I am working on designing a meta-language that supports modular definition of the language constructs. Primary objective of this endeavor is to promote “Language-as-a-Library” ideology in software language design. Thus, our sincere goal from this research is to build a framework that would facilitate rapid software language development by reusing the exiting language features as much as possible and thus, it will enable cost-effective language development. Proliferation of Domain Specific Languages (DSLs) additionally elevate the necessity of language composition, since the realization of the DSLs can only be discerned if efforts put in their implementation can somehow be minimized. Therefore, just as any other disciplines, reusability is the key here.

With the goal of designing language in a modular and reusable manner, I began a survey to figure out the existing state-of-the-art approaches that supports these kinds of features. So far, what I have learned about this topic, I will summarize in this blog.

Stratego howto: Define DynamicRules

This post is about how we can DynamicRules  in Stratego . Before explaining that ,lets revisit “why do we need DynamicRules in the first place?”.

Stratego is a strategic term rewriting system; hence inherently context-free nature of term rewriting rules only allow access to the term it is transforming. DynamicRules solves many limitations caused by the context-free nature of term-rewriting. As its name emphasizes , a dynamic rule is a rewrite rule that is defined at runtime and bind variables to its generation context. Hence, it can be used to perform context-sensitive term rewriting.

Syntax :

Defining a dynamic rule : 

rules(
drsig : l -> r
)

Undefining a dynamic rule: 

rules(
drsig :- l
)

Defining  a dynamic identity rule:

rules(
drsig : t
)

which is equivalent to following dynamic rule :  


drsig : l-> l


Domain-specific Languages(DSLs)

Domain-specific languages (DSLs) are basically programming languages. But they are specifically targeted/tailored towards particular problem domains. Hence, it implies to the fact that DSLs are narrow in applicably unlike General-purpose programming languages(GPLs)[1]; hence, DSL precisely abstracts the domain and its semantics.  At the same time, being specific to a particular problem domains make it hard to reuse and adapt to a new problem domains or to the same evolving domain with new set of requirements.

Figure 1:  DSLs are bridging the semantic gaps.

“Only way to manage complexity is to bring order to chaos”

Complex software systems consist of several concerns such as, performance, reliability , fault-tolerance, persistency. Hence, domain specialization is required to capture these concerns precisely and to perform various analyses specific to the domain. DSLs , thus reduce the complexity of complex systems  by providing high level linguistic abstraction through succinct syntax and by isolating concerns from one another which additionally results in highly cohesive sub-systems.  Following figure illustrate the fact that DSLs covers various concerns of complex software systems vertically rather than horizontally.

Figure 2 :  Vertical domain specialization of DSLs in a complex system.

Page: 1 2

Summary : “Towards Context Sensitive Domain Specific Languages” by Laird & Barrett

The high cost of developing and integrating Domain-Specific Languages (DSLs) in an existing system narrows down its applicability in other domains. In this frequently changing world, the abstraction of a domain also undergoes change, which makes the maintainability of an existing DSL costly as it is change-susceptible. To overcome the problem attached to the integration, maintainability and adaptability of DSLs, the authors promote a dynamic interpretation model that allows the adaptation of the program’s execution without any syntactic change to the DSL with respect to the varying context by decoupling the semantics of the DSL from its implementation.

To support this dynamic interpretation model, the authors propose adopting a component based model where the generic interpreter coordinates with the different runtime components to interpret the language specification. The dynamic reconfiguration of these components with respect to the varying context allows for context-sensitive semantics of the same language specification. Thus, the model can be discerned as a function that takes three inputs in form of – a language definition, components and context information and outputs a dynamic configuration that reflects the specified context. By using polymorphic counterpart, a generic interpreter can reinterpret a language types of non-functional behavior can also be accommodated in the components’ implementation, thus conforming to a particular context to support these non-functional aspects. Therefore, it is evident that this model enables dynamic customization of the language semantics based on the context and various changing requirements which, in turn, makes the DSLs highly adaptable.

In the coda, the authors argue that this model of dynamic reconfiguring the interpreter results in more flexible adaptability than the existing static model to reflect the changes in the context. Although the development cycle of a new DSL still remains the same as its static counterpart, this dynamic model has a positive impact on the maintainability of DSL. As a result of this model, the author envisage that by redefining the language for a different context, an existing DSL can be reused to spawn off a new DSL, which in turn can significantly reduce the development costs of DSLs. Subsequently, it can solve the initial problem of narrow applicability of DSLs  through reusability.

Language Composition Strategies

Throughout the years, several strategies of composing or extending software languages have been emerged. In the current and next several blog posts I will continue describing several notable approaches in composing software languages. This post will serve as an index of the various strategies.

Following are the language composition strategies that will be covered in this discussion.

• Language Reference
• Language Inheritance
• Language Specialization
• Language Embedding
• Purely modular language composition

Essence: Software Language Composition

Language composition is one of the desirable aspects of Software Language Engineering to enable reusability of the existing languages.

“From now on, a main goal in designing a language should be to plan for growth.” – Guy Steele: Growing a Language, OOPSLA’98 invited talk[1].

A language should be designed in such a way that evolving it with respect to different language constructs requires the minimum effort. It is well-recognized  that designing a high quality language requires considerable effort. Therefore, reusability is a highly desirable property in the context of software language engineering(SLE) that can support language evolution and integration in modest maintenance effort; thus, reusability of languages has become one of the primary research concern in the field of SLE.

The complexity of this problem increases with the ubiquitous proliferation of Domain-specific Languages(DSLs) as composition of various DSLs in the context of solving different problems has become a real-world use-case scenario. Wider-acceptability of DSLs further warrant modular composition of language features since the realization of the DSLs can only be discerned if efforts put in their implementation can somehow be optimized. Therefore, just as any other disciplines, reusability is the key here.

These days I am working on designing a meta-language that supports modular definition of the language constructs. Primary objective of this endeavor is to promote “Language-as-a-Library” ideology in software language design. Thus, we envisage that the outcome of this research would be a framework that would facilitate rapid software language development by reusing the exiting language features as much as possible and thus, it will enable cost-effective language development.

With the goal of designing language in a modular and reusable manner, I started with a survey to find out the existing state-of-the-art framework that supports these kinds of features. Hence, this blog contributes to this research endeavor by providing an outlook of the  existing strategies or patterns of software language composition, the technologies promoting the notion of modular and composable languages; and by reviewing the state-of-the-art approaches of software language composition in solving the relevant issues.

References

1. Jr., G.L.S.: Growing a language. Higher-Order and Symbolic Computation 12(3), 221–236 (1999) .