Add a way to specify directionality restrictions in .yaml files of aq-morphtest

[IlnarSelimcan]

In particular, what I miss in aq/yaml tests are directionality restrictions (i.e. 'make sure X is generated', 'make sure Y is analysed', 'make sure Z is not analysed) + exit codes so that it can be used on travis/circleci

[jonorthwash]

Exit codes should be a separate issue probably, but I guess you mean exit codes dependent on whether directionality tests fail?

Also, you can do generation-only tests and analysis-only tests using aq-morphtest, but it's global per run. I guess that functionality could be co-optable though.

[IlnarSelimcan]

Exit codes should be a separate issue probably, but I guess you mean exit codes dependent on whether directionality tests fail?

Exactamente.

[IlnarSelimcan]

Well, what I mean is this:

aq-morphtest foo.yaml

If all tests in foo.yaml pass, exit with 0.
Otherwise, exit with 1.

[jonorthwash]

Some ideas that come to mind are:

1. Have a keyword or symbol (like "→") that gets included in section headers to limit the directionality of tests in that section.
   • Pros: easy, compatibility with old system
   • Cons: kind of a hack (not really specifying it in yaml)
2. Have a keyword or symbol (like "→") that gets included as the first element in a section to limit the directionality of tests in that section.
   • Pros: old system files are still compatible, a real yaml way to do it
   • Cons: new system files are not backwards compatible, not semantically distinct from tests
3. Have a keyword or symbol (like "→") that gets included in the list of analyses, perhaps grouped. Something like "color<n><sg>": [ ["←", "colour"], "color" ]
   • Pros: most semantic option, old files are still compatible
   • Cons: ?
4. Make tests ordered tuples instead, with a keyword for directionality as an optional last element (or required first element?). Something like ("color<n><sg>", "color", "colour", "←")
   • Pros: somewhat semantically better
   • Cons: no out-of-the-box compatibility with old tests or old system, still not fully semantic

[jonorthwash]

Another options, kind of like options 3 and 4:

5. Treat each line as a tuple, but make it look more semantic.

     - [ бол<v><iv><aor><coop><p3><pl> , ↔ , болушат ]
     - [ бол<v><iv><aor><p3><pl> , ↔ , болушат ]
     - [ бол<v><iv><aor><p3><pl> , ← , болот ]
     - [ бол<v><iv><aor><p3><sg> , ↔ , болот ]

If you ever want to generate more than one form, you could do this:

     - [ бол<v><iv><aor><p3><pl> , ↔ , [ болушат, болот ] ]

• Pros: very semantic, human-readable, intuitive, not a hack to the current system
• Cons: not backwards-compatible at all, commas and brackets are a little unintuitive