3.1 Status

At the moment, the editor supports only a small subset of the GF grammar notation. Proper error checking is done for abstract syntax, but not (yet) for concrete syntax.

The grammars created with this editor always consists of one file for the abstract syntax, and one file for each concrete syntax.

3.1.1. Abstract syntax

The supported abstract syntax corresponds to context-free grammars (no dependent types). The definition of an abstract syntax is limited to

• a list of category names, Cat_1 ; ... ; Cat_n,
• a list of functions of the form Fun : Cat_1 -> ... -> Cat_n
• and a start category.

Available editing operations:

• Categories can be added, removed and renamed. When renaming a category, occurences of it in function types will be updated accordingly.
• Functions can be added, removed and edited. Concrete syntaxes are updated to reflect changes.
• Functions can be reordered using drag-and-drop.

Error checks:

• Syntactically incorrect function definitions are refused.
• Semantic problem such as duplicated definitions or references to undefined categories, are highlighted.

3.1.2. Concrete syntax

At the moment, the concrete syntax for a language L is limited to

• opening the Resource Grammar Library modules SyntaxL and ParadigmsL, LexiconL and ExtraL,
• linearization types for the categories in the abstract syntax,
• linearizations for the functions in the abstract syntax,
• parameter type definitions, P = C_1 | ... |C_n,
• and operation definitions, op = expr, op : type = expr,

Available editing operations:

• The LHSs of the linearization types and linearizations are determined by the abstract syntax and do not need to be entered manually. The RHSs can be edited.
• Parameter types can be added, removed and edited.
• Operation definitons can be added, removed and edited.
• Definitions can be reordered (using drag-and-drop)

Also,

• When a new concrete syntax is added to the grammar, a copy of the currently open concrete syntax is created, since copying and modifying is usually easier than creating something new from scratch. (If the abstract syntax is currently open, the new conrete syntax will start out empty.)
• When adding a new concrete syntax, you normally pick one of the supported languages from a list. The language code and the file name is determined automatically. But you can also pick Other from the list and change the language code afterwards to add a concrete syntax for a language that is not in the list.

Error checks:

• The RHSs in the concrete syntax are checked for syntactic correctness by the editor as they are entered.(TODO: the syntax of parameter types is not check at the moment.)
• Duplicated definitions are highlighted. Checks for other semantic errors are delayed until the grammar is compiled.

3.2. Compiling and testing grammars

When pressing the Compile button, the grammar will be compiled with GF, and any errors not detected by the editor will be reported. If the grammar is free from errors the user can then test the grammar by clicking on links to the online GF shell, the Minibar or the Translation Quiz.

3.3. Grammars in the cloud

While the editor normally stores grammars locally in the browser, it is also possible to store grammars in the cloud. Grammars can be stored in the cloud just for backup, or to make them accessible from multiple devices.

There is no automatic synchronization between local grammars and the cloud. Instead, the user should press to upload the grammars to the cloud, and press to download grammars from the cloud. In both cases, complete grammars are copied and older versions at the destination will be overwritten. When a grammar is deleted, both the local copy and the copy in the cloud is deleted.

Each device is initially assigned to its own unique cloud. Each device can thus have its own set of grammars that are not available on other devices. It is also possible to merge clouds and share a common set of grammars between multiple devices: when uploading grammars to the cloud, a link to this grammar cloud appears. Accessing this link from another device will cause the clouds of the two devices to be merged. After this, grammars uploaded from one of the devices can be downloaded on the other devices. Any number devices can join the same grammar cloud in this way.

Note that while it is possible to copy grammars between multiple devices, there is no way to merge concurrent edits from multiple devices. If the same grammar is uploaded to the cloud from multiple devices, the last upload wins. Thus the current implementation is suitable for a single user switching between different devices, but not recommended for sharing grammars between multiple users.

Also note that each grammar is assigned a unique identity when it is first created. Renaming a grammar does not change its identity. This means that name changes are propagated between devices like other changes.

3.4. Future work

This prototype gives an idea of how a web based GF grammar editor could work. While this editor is implemented in JavaScript and runs in the web browser, we do not expect to create a full implementation of GF that runs in the web browser, but let the editor communicate with a server running GF.

By developing a GF server with an appropriate API, it should be possible to extend the editor to support a larger fragment of GF, to do proper error checking and make more of the existing GF shell functionality accessible directly from the editor.

The current grammar cloud service is very primitive. In particular, it is not suitable for multiple users developing a grammar in collaboration.

3.5. Related documents

• The GF Grammar Compiler API.
• Slides from a presentation at the MOLTO meeting in Göteborg, March 2011.