\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.