You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR proposes an own JSON-like grammar for KeY settings and
configuration.
## Status Quo
Currently, we store our settings inside of Java Properties files. Either
for global settings inside `$HOME/.key` or inside of proof files. Java
Properties are a simple and easy solution, but also have some
disadvantages. For example,
* the lack of type safety (everything is a string),
* missing positional information (we are not able to give error messages
regarding incorrect settings),
* no support for adding comments, and
* no complex data structures.
## Proposal
I propose an own grammar, written an ANTLR4, for KeY's configuration
that is compatible with JSON and the grammar of KeY.
### Why an own grammar? (or why not JSON, TOML or Co.)
There are many popular grammars for configuration files, e.g., JSON,
TOML and YAML. I decided against them for the following reason:
* The grammar must be embeddable into our KeY files and grammar.
* No external dependencies and complexity. The grammar is small, and
parsing is done in a few hundred boring LoC.
* No support for storing additional information, like comments.
### The grammar
The grammar is an extension of JSON, allowing comments, multiline
strings, non-quoted keys, etc. An example is given in the comments
below.
The grammar is a recursive definition of values, which can simply be
expressed as an ANTLR4 grammar.
```antlr4
// Config
cfile: cvalue*;
ckv: doc=DOC_COMMENT? ckey ':' cvalue;
ckey: IDENT | STRING_LITERAL;
cvalue:
IDENT #csymbol
| STRING_LITERAL #cstring
| BIN_LITERAL #cintb
| HEX_LITERAL #cinth
| MINUS? INT_LITERAL #cintd
| FLOAT_LITERAL #cfpf
| DOUBLE_LITERAL #cfpd
| REAL_LITERAL #cfpr
| (TRUE|FALSE) #cbool
| LBRACE
(ckv (COMMA ckv)*)? COMMA?
RBRACE #table
| LBRACKET (cvalue (COMMA cvalue)*)? RBRACKET KeYProject#986
```
### Changes
1. Settings inside proof files would no longer be strings instead the
section follows the grammar above.
2. All configuration files inside `$HOME/.key` will follow the new
grammar. In case of the presence of a properties or and JSON file, the
JSON takes advantage.
3. The interface for settings (`#writeSettings` and `#readSettings`) is
extended with two new methods which take an object of `Configuration`
(which is an extended `Map<String, Object>`) instead of a `Properties`
object.
### Migration strategies
In KeY files, we decide, based on the grammar (STRING_LITERAL vs.
JSON-object), which settings handling should be to trigger. All settings
are written as JSON-objects.
0 commit comments