The mini-projects occupied one day of the course. Students worked individually, in pairs, or in groups of three on project topics that were either suggested by the teachers or were devised by the students based on the themes of the course. On Friday afternoon the students gave short presentations describing what they had done and, in some cases, demonstrated the software that they had written. Short summaries of the mini-projects are given below, in the order in which the work was presented on Friday afternoon.
ICode is used internally within P/FDM to represent queries in a form that can be manipulated within Prolog. However, ICode appears rather obfuscated to a human reader. We present a limited pretty-printer taking input code in a subset of ICode and pretty-printing an equivalent list comprehension. This is realised is stages: First a parser created in the Syntax Definition Formalism (SDF2) converts ICode to an internal representation as an abstract syntax tree (AST).* Next, this AST is lightly rewritten in Stratego, a strategy-based term-rewriting language. Finally, the Stratego code linearises the AST using a hard-coded pretty printer.
Future work on this tool could yield a pretty printer handling the full ICode language. To accomplish this, one would appropriately extend the concrete and abstract syntax definitions, add simplifying rewrites for the new abstract syntax, and extend the pretty printing function. The tool could be greatly improved (with respect to design) if the pretty printing were refactored by writing an SDF2 definition for the output (list comprehension) syntax.
* The parser is currently non-functional due to a minor bug (in our code) related to passing lists between SDF2 and Stratego.
Visualising the "call graph" of a list comprehension may aid the understanding of what is going on, especially for beginners. We have implemented a simple preprocessor for Haskell that adds monad comprehension syntax to the language. By constructing a suitable monad (with a zero) we can then more or less transparently collect the information needed to display call graphs for arbitrary list comprehensions.
I implemented an abstract syntax for list comprehensions, together with an evaluator (everything in haskell). I then started to implement structural optimizations, such as:
[...|..., (P and Q), ...] -> [...|..., P, Q, ...]
[...|x<-xs, ..., y<-ys, ..., P(x), ...] -> [...|x<-xs, ..., P(x), y<-ys, ...]
I was planning to flatten the generators too, but didn't have the time.
[...|x<-[f(y)|y <- ys, P(y)], ...] -> [...|y <- ys, P(y), let x = f(y), ...]
I test ran a few examples that could obviously be optimized using the rules above, and found some speedup when evaluating the optimized versions, compared to the unoptimized ones.
We wrote a command-line tool in jython for querying an Oracle database. The input queries are in list comprehension format, and can (among others) contain CNF-style logical expressions. The tool parses the query and converts it to SQL in order to use JDBC for communicating with a (possibly remote) database.