Identity

This is a very simple lens. It maps between identical concrete and abstract models. From concrete to abstract models, get simply copies the concrete model. In the opposite direction, put and create copy the abstract model:

1. id.get(c) = c
2. id.put(a, c) = a
3. id.create(a) = a

The notion l.f refers to the function f of a particular lens l of interest. id denotes the identity lens. This lens obeys all three round-tripping laws:

1. id.get(id.put(a, c)) = id.get(a) = a
2. id.get(id.create(a)) = id.get(a) = a
3. id.put(id.get(c), c) = id.put(c, c) = c

Composition

This lens combines two lenses l1 and l2 sequentially to a new lens (l1 ; l2). To get an abstract model from a concrete model c, l1.get and l2.get are applied sequentially. The put function of the combined lens is slightly more difficult. First, l2.put is applied to put back the abstract model into the temporary model l2.get was applied to. This temporary model is the result of l1.get. This step yields an updated temporary model. In the next step, the updated temporary model is put back into the original concrete model by applying l1.put. The create function is simple again. First, l2.create is applied to the abstract model. Afterwards, l1.create is applied to the result:

1. (l1 ; l2).get(c) = l2.get(l1.get(c))
2. (l1 ; l2).put(a, c) = l1.put(l2.put(a, l1.get(c)), c)
3. (l1 ; l2).create(a) = l1.create(l2.create(a))

The composition (l1 ; l2) fulfils the round-tripping laws if l1 and l2 do so:

1. (l1 ; l2).get((l1 ; l2).put(a, c)) =
   l2.get(l1.get(l1.put(l2.put(a, l1.get(c)), c))) =
   l2.get(l2.put(a, l1.get(c))) = a
2. (l1 ; l2).get((l1 ; l2).create(a)) =
   l2.get(l1.get(l1.create(l2.create(a)))) =
   l2.get(l2.create(a)) = a
3. (l1 ; l2).put((l1 ; l2).get(c), c) =
   l1.put(l2.put(l2.get(l1.get(c)), l1.get(c)), c) =
   l1.put(l1.get(c)), c) = c

Defining a DSL

We now take identity and composition as a starting point for a bidirectional transformation language working on terms. First, we need to define a concrete syntax for this language. For this purpose, the metalanguage of choice is SDF which integrates lexical and context-free syntax in one formalism, supports arbitrary context-free grammars, and enables language reuse by a module system. Here is an SDF module defining a concrete syntax for the two lenses discussed so far:

module StrategicLenses

imports Common

exports context-free syntax
"id"          -> Lens     {cons("Id")}
Lens ";" Lens -> Lens     {left, cons("Comp")}


This module reuses another module called Common which provides definitions for syntactic sorts like ID, INT and STRING as well as typical layout definitions including comments. For each lens, there is a rule defining the syntactic sort Lens. The second rule is attributed being left associative to avoid ambiguity. Finally, both rules are attributed with a constructor name for nodes in abstract syntax trees. With SDF, abstract syntax trees are represented as terms. A signature for such terms can be derived from a SDF syntax definition. Here is the signature for our transformation language:

module StrategicLenses

signature constructors
Comp : Lens * Lens -> Lens
Id   : Lens


We rely on such term representations when we specify the dynamic semantics of both lenses by term rewriting rules in Stratego. Here are the rules for identity:

module Semantics

imports libstratego-lib StrategicLenses

rules
get    : (Id(), c)    -> c
put    : (Id(), a, c) -> a
create : (Id(), a)    -> a

This module imports the Stratego standard library and the signature  StrategicLenses mentioned before. There is a rewrite rule for each lens function. The fundamental idea is to rewrite tuples consisting of a lens and the arguments of the function into the result of the function. The first rule specifies the get function. It rewrites a pair consisting of the identity lens and a concrete model c to c. The second rule specifies the put function. Since this function takes two arguments — an abstract model a and a concrete model c, it rewrites a triple consisting of the identity lens, a, and c to the abstract model a. The third rule specifies the create function analogously.

Here are the rules for composition:

rules
get    : (Comp(l1, l2), c)    -> <get> (l2, <get> (l1, c))
put    : (Comp(l1, l2), a, c) -> <put> (l1, <put> (l2, a, <get> (l1, c)), c)
create : (Comp(l1, l2), a)    -> <create> (l1, <create> (l2, a))

Note that these rules have the same name as for identity. But they distinguish in the matching pattern for the lens. Here, a composition lens is matched and the two sub-lenses are bound to l1 and l2, respectively. To specify the result of the functions, we need to apply rewriting rules recursively. Application of a rule is denoted by angle brackets. For example, the right-hand side of the first rule reads: Apply get to a pair consisting of l2 and the result of applying get to the pair (l1, c). This enables us to specify the three lens functions in a notation very similar to the one in the beginning of this post.

Coming up next: Some useful lenses working on terms.

Lenses provide means to specify well-behaved bidirectional transformations between more concrete “things” — let’s say models — and more abstract models.  Given a set C of concrete models and a set A of abstract models, a lens comprises three total functions:

1. get: C → A
2. put: A × C → C
3. create: A → C

The get function derives an abstract model from a concrete model. This abstract model is basically a view on the concrete model. The put function takes an updated abstract model and its original concrete model as arguments, yielding an updated concrete model which reflects the updates of the abstract model. If no concrete model exists, the create function constructs a concrete model from an abstract one. To ensure well-behaveness these functions must obey the following round-tripping laws:

1. get(put(a, c)) = a
2. get(create(a)) = a
3. put(get(c), c) = c

If we update an abstract model and propagate this update back into an old concrete model by a lens’ put function, we expect that the new concrete model reflects this update completely. The first law — the PutGet law — guarantees this. It requires that applying the lens’ get function to the new concrete model must yield exactly the updated abstract model. That is, no update detail is lost during the put. Similarly, we expect a concrete model which is initially created from an abstract model by a lens’ create function to contain all the information of the abstract model. We must be able to derive the very same abstract model from the concrete model by the lens’ get function. This is ensured by the second law — the CreateGet law. Finally, if we derive an abstract model from a concrete one by a lens’ get function and put this abstract model without any modifications back into the original concrete model, we expect the concrete model to stay unmodified, too. The third law — the GetPut law — enforces this behaviour.

Well, this is simply what we expect from a bidirectional transformation. We can implement the three functions of a lens in any programming language and have to prove the three round-tripping laws. The first step might be quite easy and the second one might become a nightmare, particularly if implementation changes. So what is so special about lenses? Where is the benefit? The idea is to use lenses as first class citizens in a bidirectional transformation language. This language provides a set of basic lenses and combinators for these lenses as means to specify bidirectional transformations. You can simply define new lenses by combining existing lenses. The round-tripping laws are proven for the basic lenses and the static semantics of the language guarantee that a combination of lenses is well-formed and the round-tripping laws hold for the combination as well. Dynamic semantics of the language specify how the three functions of a combined lens can be derived from its constituting base lenses and combinators. Thus, dynamic semantics release you from writing separate functions for your bidirectional transformation while static semantics release you from proving the round-tripping laws.

Coming up next: How to specify lenses in Stratego.

I needed to install both on a Mac running Snow Leopard. Here is how it works.

1. Installing Apple’s Xcode Developer Tools.

Xcode is Apple’s development environment for Mac OS X. You will find an installer on your Snow Leopard installation DVD and on the Apple Developer Connection site. Make sure to install the optional components for Unix development. Next, you should install the latest software updates for Mac OS X and Xcode by running Software Update.

2. Installing MacPorts.

MacPorts is a free and open-source package management system that simplifies the installation of open-source software on a Mac. Follow the instructions on the MacPorts installation site. For me, the Snow Leopard Package installer worked fine. Make sure to update MacPorts by running

sudo port -v selfupdate

Afterwards, your ~/.profile file should include this line:

export PATH=/opt/local/bin:/opt/local/sbin:$PATH

3. Installing Nix.

Nix is another free and open-source package management system. In order to build Nix from source, you will need some tools which can easily be installed with MacPorts:

sudo port install curl m4 autoconf automake pkgconfig libtool

Now, you should get the source of the latest development release of Nix. After extraction, switch to the source directory and build Nix using these commands:

./configure
make
sudo make install
sudo chown -R $USER /nix

Next, you need to add these lines to your ~/.profile file:

. /usr/local/etc/profile.d/nix.sh
export PKG_CONFIG_PATH=~/.nix-profile/lib/pkgconfig:$PKG_CONFIG_PATH

4. Installing WebDSL.

WebDSL is continuously built, tested and released by Hydra, a Nix-based continuous build system. You register for the latest builds by running these commands:

nix-channel --add http://hydra.nixos.org/channel/latest
nix-channel --update

Now, you can install the latest build of WebDSL:

nix-env --system-filter x86_64-darwin -i webdsl

The --system-filter x86_64-darwin option ensures that you get the 64-bit version appropriate for Snow Leopard. Since 64-bit pointers need some space, you need to increase the stack size. Add this line to your ~/.profile file:

ulimit -s 64000

5. Installing Apache Tomcat.

Apache Tomcat provides a web server environment. In this environment, you can run your web applications developed with WebDSL. You should download the Binary Distribution Core from the Apache Tomcat Download Page. Extract the archive to an appropriate directory. Include the bin subdirectory to your PATH environment in your .profile file:

export PATH=YourInstallationDirectory/bin:$PATH

6. Installing MySQL.

MySQL is a relational database management system. Your WebDSL applications rely on it for data persistence. You can download a package installer for the current version of the MySQL Community Server. Make sure to get the 64-bit version and run the package installer. Furthermore, you should install the preference pane by double-clicking it. For more details, see the installation instructions. Update your PATH environment in your .profile file:

export PATH=usr/local/mysql/bin:$PATH

7. Test your installation.

Now it’s time to test your installation. First, start Tomcat:

startup.sh

Next, start MySQL from the MySQL preference pane:

You have now a working runtime environment for dynamic web applications. In order to test WebDSL, create a sample application by running

webdsl new

You need to provide some information. In most cases, default values work fine. Here is a sample configuration (bold user input):

Application name (one word): test
---- Database information ----
You will now be asked for database info such as hostname, username, password and database. Do note that this script will check if this information is valid, if it is not, it will attempt to create the database with the given username and password for you.
MySQL Host [localhost]:
MySQL Username [webdsluser]:
MySQL Password []:
MySQL Database [webdsldb]:
Hibernate database mode (create-drop / update / false) [create-drop]
Now checking if database info works.
Enter password:
Unsuccessful, will now attempt to create database. For this we need your MySQL's root password (by default this is blank).
MySQL root password:
Now checking if database creation worked...
Enter password:
Yes!
Do you want to configure your application for sending email? [y/n] n
---- Tomcat information ----
Tomcat path for deployment [/opt/tomcat]: /Users/guwac/Programs/apache-tomcat-6.0.20
Now creating bare-bones application in application.app...
override r--r--r-- guwac/staff for APPLICATION_NAME.app? n
Application created in application. You can now cd to this directory and call the webdsl script to compile your program.


You can now build and deploy the test application:

cd test
webdsl build
webdsl deploy


If everything worked fine, the test application is running at http://localhost:8080/test. Finally, you can stop MySQL from the MySQL preference pane and stop Tomcat by running

shutdown.sh

8. Have fun.

I needed to install the framework on a Mac running Snow Leopard. Here is how it works.

1. Installing Apple’s Xcode Developer Tools.

Xcode is Apple’s development environment for Mac OS X. You will find an installer on your Snow Leopard installation DVD and on the Apple Developer Connection site. Make sure to install the optional components for Unix development. Next, you should install the latest software updates for Mac OS X and Xcode by running Software Update.

2. Installing MacPorts.

MacPorts is a free and open-source package management system that simplifies the installation of open-source software on a Mac. Follow the instructions on the MacPorts installation site. For me, the Snow Leopard Package installer worked fine. Make sure to update MacPorts by running

sudo port -v selfupdate

Afterwards, your ~/.profile file should include this line:

export PATH=/opt/local/bin:/opt/local/sbin:$PATH

3. Installing Nix.

Nix is another free and open-source package management system. In order to build Nix from source, you will need some tools which can easily be installed with MacPorts:

sudo port install curl m4 autoconf automake pkgconfig libtool

Now, you should get the source of the latest development release of Nix. After extraction, switch to the source directory and build Nix using these commands:

./configure
make
sudo make install
sudo chown -R $USER /nix

Next, you need to add these lines to your ~/.profile file:

. /usr/local/etc/profile.d/nix.sh
export PKG_CONFIG_PATH=~/.nix-profile/lib/pkgconfig:$PKG_CONFIG_PATH

4. Installing Stratego/XT.

Stratego/XT is continuously built, tested and released by Hydra, a Nix-based continuous build system. You register for the latest builds by running these commands:

nix-channel --add http://hydra.nixos.org/channel/latest
nix-channel --update

Now, you can install the latest build of Stratego/XT:

nix-env --system-filter x86_64-darwin -i aterm-2.5 java-front sdf2-bundle strategoxt

The --system-filter x86_64-darwin option ensures that you get the 64-bit version appropriate for Snow Leopard.

5. Installing missing libraries.

Usually, this step should not be necessary but it was for me. The Stratego compiler was missing these two libraries:

/usr/lib/libreadline.6.0.dylib
/usr/lib/libhistory.6.0.dylib

You can fix this by installing the readline libraries with MacPorts and creating symbolic links for the missing libraries:

sudo port install readline
sudo ln -s /opt/local/lib/libreadline.6.0.dylib /usr/lib/
sudo ln -s /opt/local/lib/libhistory.6.0.dylib /usr/lib/

6. Have fun.