Abstract Domain Language
From TheSoftwareFactory
| ADL |
| A generic language syntax that can be used to implement different DSLs using one common parser and visitor. |
| Author |
|---|
| xtof |
| Quick Links |
|
| Availability |
|
Is it a programming language ? Is it a Mark-Up language ? Is it a DSL? No it's ADL, the Abstract Domain Language.
We use ADL as a general purpose language to describe ... lots of things in different domains. In fact I should rather say that "We use DSLs build on top of ADL, as implementations of the Abstract Domain Language. The main goal is to have an easy to type, uniformly structured language to quickly write down mostly hierarchical definitions of domaininformation. But let's get you up to speed and go back in time ...
Contents |
History
ADL was conceived some time ago, while we were working on a tool that in the end would consume UML. To speed up development, we came up with ADL as a temporary stand-in for XMI. XMI is far from a nice format and there aren't any decent reusable XMI parsers out there, which allowed us to quickly start testing small UML model snippets. We didn't want to loose time trying to find one, and started of with a simple homegrown DSL to describe applications in the form of models. ADL, the Application Definition Language was born as a temporary solution.
ADL soon showed its merits, because, we could very quickly write down small models to test our tool, without starting up a CASE tool, drawing the model, export it into XMI,... Just an instance of emacs and there you go, yet another model ready to be tested.
Time goes by, projects evolve and other exiting things came along; still somehow connected to the initial project, but from a different angle. We now wanted to make a Javascript implementation wrapping the HTML5 Canvas element, to display UML models. Reusing ADL to describe the models was clearly the way to go, because, we wanted this to be an easy solution to introduce UML models on any webpage, without the requirement to upload images and off course no copy pasting XMI into a webpage.
While designing the tool, we split off the capability to draw on the canvas and made the UML implementation an implementation on top of the low-level canvas wrapper. ADL evolved to a more general purpose language, no longer solely for describing UML models, but now also generic shapes. At that point, the Application Definition Language became the Abstract Domain Language on top of which e.g. our UML-profile was a Domain Specific implementation.
Concepts
To ADL everything is a (abstract) "construct". A construct is something that at least has a type and a name. Besides those some optional additional kinds of information can be added to it:
- One can add annotations to construct, allowing arbitrary information to be added.
- Constructs can inherit from other constructs, through which they copy the other construct's information.
- Constructs can be "modified" through key-value or simple switch-style modifiers.
- Constructs can be bound to other constructs, by wich they share the same value. Because constructs can have a value, this value can also be set at definition time by means of a default value.
- Finally, constructs can have children, which are again constructs.
[@annotation]
constructType name
: superConstructType
+modifier="value" +switchModifier
:= boundConstruct
= "defaultValue" {
...
}
Justifying ADL
The first comment almost an reader by now will have, is "Why reinvent the wheel? Why not reuse something that exists?" And I share this opinion. The fact that I still publish this online, means that I've found enough reasons to justify yet another language thingie.
Goal
Let's start with listing my goals for ADL:
- hierarchical
- generic parser
- specialization through profiles
- specialisation for some common concepts
- easy to type
- easy to read
- small footprint
Hell that look a lot like features of XML:
- hierarchical
- generic parser
- specialization through profiles
And that's where it ends ... according to me.
- specialisation for some common concepts : XML has a notion of an element and an attribute. Specializing concepts can be done through named attributes.
- easy to type : Well, given the verboseness of XML, it's not the nicest thing to type manually. Given the pletora of XML editors out there, I seem to be right on this one ;-)
- easy to read : The idea is simple, but trying to grasp the overall content of an XML encoded piece of data, can be rather daunthing. Not for simple datasets, but when things get a bit more complex, XML quickly looks like a labyrinth.
- small footprint: XML has a lot of overhead, which makes the size grow rather quickly.
And what about JSON?
- hierarchical
- generic parser
- easy to type
- easy to read
- small footprint
True, JSON seems to have a larger match with respect to my goals, but two very important ones are still missing:
- specialization through profiles
- specialisation for some common concepts
I find these important, because they aid in fact three other goals:
- easy to type
- easy to read
- small footprint
When I find the time, I hope to finish a page on Comparing ADL to XML to illustrate these differences.
Examples
It's off course hard to show examples of something "abstract". The only way to do this is to use examples of implementations.
UML
As explained in the prior part about its history, ADL started off as a textual representation of UML.
class myClass : mySuperClass +public {
attribute myAttribute : String +private ="defaultValue";
operation myOperation : Boolean {
parameter param1 : Integer;
}
}
Shapes
When we separated the rendering of the visuals from the UML concepts into a shape rendering component of its own, ADL moved along with it, offering the format for a Shapes DSL:
diagram myDiagram {
[@10,10] rectangle myRect +geo="50x50" +blue;
[@35,35] circle myCircle +rad=25 +blue;
}
Projects using ADL
- As I explained above, ADL was conceived while working on a UML-based tool and later seperated from that project in a project focussing on rendering shapes on an HTML5 Canvas Element. This project is Canvas2D.
- The project that triggered the creation of Canvas2D, currently the main user of it, and therefore also a big user of ADL is our UmlCanvas. A UML implementation on top of Canvas2D which allows definition of UML diagrams in any webpage on any browser with Javascript enabled.
Features and Future
Currently the distribution contains a minimal implementation of ADL in Javascript. That's because that's what I currently need to be able to get the Canvas2D and UmlCanvas projects up and running. That doesn't mean that ADL isn't going to evolve. We already have a lot of experience with ADL in its Java incarnation, which we used on a previous project. Once Canvas2D and UmlCanvas are released, we are going to continue to evolve ADL to what we currently know and have planned.
There is a lot more to ADL than only the static construct definition part. ADL also has a set of directives that allow dynamic interaction with the constructs. Further, ADL also has a profile definition system to describe the implementations on top of ADL, thus enabling self-validations. And a lot more.
As soon as we start fully implementing ADL, we will also start shipping it in more languages. Java to start with off course, but any language that has a LALR parser generator which start from some form of BNF, should be a candidate.
License and Credits
ADL is licensed under the BSD License. Which basically allows you to use it in whatever way you like, just keep a reference to this origin. Like many open source work, this project stands on the shoulders of giants. The following projects are imported to create the ADL experience:
- JSCC is a LALR(1) parser and lexical analyzer generator for JavaScript, written in JavaScript. JSCC is written by Jan Max Meyer and is released as open source software under the Artistic License.
- ProtoJS, our own, ultra small, JavaScript library with extensions to the language.
