Some ideas for making advanced Stratego features more accessible to new users.

Goals

• Easy to define a syntax for language X and implement a source-to-? or source-to-source transformation for it.

• Easy to define a transformation for language X, which is already supported by some package (e.g. java-front).

• Easy to reuse existing syntax definitions. Languages should be 'components' that more or less hide their internal implementation.

XT Archives: Tool and File Integration

One of the problems of XT is that there are many file types for a single subject language. These file types are used by several tools. The users needs to know how to generate all these files and he needs to pass these files explicitly to all the tools.

xtar (xt archive) is a solution to this problem. xtar collects the standard set of files for a specific language into a single zip archive (compare to a jar file). This archive can then be passed to all the XT tools and they just take out the files that they need. The user doesn't need to know what specific files a tool need.

The only input of xtar tool is an SDF module. It takes a -i argument for this module and probably should accept the include flags of pack-sdf. xtar will integrate the following tools:

• pack-sdf
• sdf2table
• sdf2rtg
• rtg2sig
• ppgen

The resulting xtar will contain all the files related to a language: a A.def, A.tbl, A.rtg (A.rtg-nf), A.str (A.rtree) and A.pp (A.pp.af). Hence, the xtar contains all the files required to implement a transformation for language A. Furthermore, the archive might contain meta information (compare the a jar manifest).

Components of this archive, in particular the .pp, must be overrideable.

---

Below are some more adventurous and unclear ideas. These are not directly related to the idea of XT Archives.

---

Flexible Composition of XTC Repositories

Problem: users more or less need to be in an Autoconf/Automake environment if they need to do composition.

The XTC repository mechanism should be more flexible. Most important: a tool should be able to locate resources from multiple repositories. Also, repositories should be more dynamic: currently repositories are only constructed at install-time.

The configuration of the XTC repositories to use should be more flexible. It should be possible to extend the resources visible to StrategoXT components, without difficult repository construction.

Ideas:

• Automatically load repositories in a /home/fred/.xtc directory. Packages could provide an 'activate' tool that adds their repository to this directory.

• Use a ":" separated environment variable 'XTC_REPOS'. This variable can contain multiple XTC repositories, which are all loaded.

• On-request extension of the XTC bindings. The zip archive of language specific files should for example be accepted by the Stratego compiler. These files are registered and the entries refer to the files in the zip file.

(Karl) I specifically suggest some configuration guidelines for the XTC tools:

* Every XTC tool will perform a fixed search for dynamic configuration settings, starting with searching for ${prefix}/etc/xtc/xtc.conf, then ${HOME}/.xtc/config (or .xtc.conf), then any environment variables, such as XTC_REPOS. Settings will be overriden upon rediscovery.

* Easy programmatic inspection of the XTC repository, and xtars, allowing for searching, e.g.: xtc-query Java.sdf will find all available Java.sdfs, and explain the precedence order. (User may have his own experimental stuff in ~/.xtc/myjavastuff.xtar that inadvertently takes precedence over /usr/share/xtc/myjavastuff.xtar).

Also:

* Documentation; inasmuch as this exists, it should either be in the xtar bundle itself, or referenced in a way that allows for easy queries and subsequent display in a web browser.

In this way, the 'language archive' can be used completely transparantly by the Stratego compiler and other tools.

Include Resources in Executable

Transformation tools should be more or less self-contained, at least they should contain their data files to avoid all the problems in locating this data.

At least, all external files can be packed into one xtar, which is bundled along with the binary. If all auxiliary tools know how to deal with xtars, we have reduced the deployment from binary + heaploads of extra stuff to binary + data, which is already a big improvement.

• Parse-tables could be included in the binary. They can be written to a temporary file, or libsglr can be used.

• Transformation tools created in this way should not have a built-in default repository: they should be portable the .xtc mechanism can be used as a default a repository.

• In-program resources (such as the parse table) should be registered in XTC and can be used as ordinary XTC resources.

• XTC compositions can be written in a non-automake enviroment.

Inline Meta Files

This is all just an extension of the existing XTC mechanism. Another thing we would like to change is the .meta file. Defining meta information in the program itself is more comprehensible for new users, and it is easier to move files around. The solution is to add a header to a Stratego module. This header will be read separately and the real body will be parsed with the specified syntax. Preferably, this header should be in a concrete syntax.

Example:

    meta
      syntax = StrategoJava

    module foo
    imports
      Java
      java-xtc-tools

    strategies
      main =
        xtc-io-wrap(
          xtc-parse-java
        ; do-my-stuff
        ; xtc-pp-java
        )