Deprecating error-chain.

For more accurate error messages with or_exit. See #16.

Some documentation and a few examples would be quite useful for new users.

The feature definition file is restricted to ASCII_ALPHANUMERIC feature names. I don't know if that's wanted, but there are probably cases where people (me) have features with underscores or some other non-ascii-alphanumeric chars.

Quick fix for this would be replace ASCII_ALPHANUMERIC in the grammar definition file by a newly defined char rule:

feature_name = ${ char+ }
char = _{ !(WHITESPACE | "|" | ":" ) ~ ANY }

or a more defensive change to feature_name by whitelisting non-ascii-alphanumeric letters explicitly

feature_name = ${ (ASCI_ALPHANUMERIC | "_" | "-" )+ }

We vectorize all the data before optimizing the graph. This worked fine when we were just storing indices, but now that we store embeddings for embedding layers, memory use is getting out of hand (~30GB on TüBa-D/Z).

I guess we we should generate the batches on the fly instead.

There is a lot of overlap between the transition-specific lookup and feature table lookup. This can be factored out to one class that replaces Numberer.

Maybe this should be a separate crate, because it is generally useful.

Currently, dpar assumes that all dependencies are projective, even though they are read from the non-projective column.

Support for pseudo-projective parsing should be added to deal with non-projective structures.

Support dynamic oracles for the common transition systems (at the very least arc-eager).

The CoNLL-X features field is often used for e.g. adding a morphological analyses for tokens. Since these are effective parsing features, they should be addressable too.

We probably want to put some restrictions on the permitted formatting of the field. E.g. using the vertical bar (|) to separate features seems to be more or less standardized. However what the actual features look like isn't.

For our purpose it would be best if these were attribute-values (e.g. with the format a=v or a:v), which would allow addressing specific features. For instance:

STACK 0 FEATURE number STACK 1 FEATURE number

It would be nice if there are some sample models that are ready to use.

Ragel dropped support for all languages outside C/C++/ASM. To change/regenerate the addressed value parser, one has to manually compile an old Ragel version.

It would be nicer to just switch to nom, which is Rust-native and well-maintained.