Today, i committed Stockholm's first version of the SQL persistence layer based on Stefan Szeiger's scala-query to github.
Let's take a look at how this all fits together by way of a familiar example. Our old friend, the lambda calculus, is a paradigmatic DSL -- the mother of all DSL's, with that peculiar kind of specificity that makes it generic again. Here's the syntax of a version of the lambda calculus in the input language for Stockholm.
From this language we generate
- a parser for a concrete language that we can type in at the keyboard;
- latex'ed and html'd versions of documentation of the concrete syntax;
- an abstract syntax that doubles as a data model, expressed as Java objects that are accessible from Scala;
- a persistence mapping for the data model;
- a lift-based web wrapper around a minimalist REPL that simply reads the concrete syntax and pretty prints the abstract syntax tree corresponding to the input expression
- as well as links to pages for the documentation on the lift site map;
- a RabbitMQ transport for JSON serialized versions of the data model.
The form is backed by the following scala code which determines what the user has asked to do with the source (parse it, evaluate it, type it or send a JSON representation of it to a queue).
Parsing an abstraction like the one in the top window will result in an instance of the Java object that represents Abstractions
Instances of this object can be stored and retrieved via the scala-query mapping for the Abstraction object.
These bits and bobs enable the sorts of communication flows depicted in this diagram.
The point, of course, is that all of this infrastructure is completely generated. Instead of our old standby, the lambda calculus, we could have put in a description of patient records in a health care information processing system.