\shortsection{A Case Study in Language Prototyping}

A strong case for BNF Converter is the prototyping of new
languages. It is easy to add and remove language
features, and to test the updated language immediately.
Since standard tools are used, the step from the 
prototype to a production-quality front end is small,
typically involving some fine-tuning of the abstract
syntax and the pretty printer. We have a large-scale
experience of this in creating a new version of the
language GF (Grammatical Framework, \cite{GF-paper}). 

The main novelties added to GF were 
a module system added on top of the old GF language, 
and a lower-level language GFC, playing the role of 
``object code'' generated by the GF compiler. 
The GF language has constructions mostly familiar from functional
programming languages,
and the size of the full grammar is similar
to ANSI C; GFC is about half this size. 
We wrote the LBNF grammar from scratch, one motivation
being to obtain reliable documentation of GF. 
This work took a few hours. We then used the skeleton file
to translate the generated abstract syntax into the existing
hand-written Haskell datatypes; in this way, we did not 
need to change the later phases of the existing compiler (apart from
the changes due to new language features). In a couple of days,
we had a new parser accepting all old GF files as well as 
files with the new language features. Working with later compilation
phases suggested some changes in the new features, such as adding
and removing type annotations. Putting the changes in place never required
changing other things than the LBNF grammar and some clauses in
the skeleton-based translator.

The development of GFC was different, since the language
was completely new. The crucial feature was the symmetry between
the parser and the pretty printer. The GF compiler generates 
GFC, but it also needs to parse GFC, so that it can use precompiled
modules instead of source files. It was reassuring to know
that the parser and the pretty printer completely matched.
As a last step, we modified the rendering function of the GFC
pretty printer so that it did not generate unnecessary spaces;
GFC code is not supposed to be read by humans. This step initially
created unparsable code (due to some necessary spaces having been
omitted), which was another proof of the value of automatically
generated pretty-printers.

In addition to the GF compiler written in Haskell, we have been
working on GF-based applets (``gramlets'') written in Java.
These applications use precompiled GF. With the Java parser
generated by the BNF Converter, we can guarantee that the GFC code generated
by the Haskell pretty-printer can be read in by the Java application.
