So, here is the upgraded syntax:
Feature | Example | Acceptable results for "@test@" (one per line) |
---|---|---|
Basic literal | test: "abc" | abc |
Sequence | test: "a::b::c" | a b c |
In-line sequence | test: "[a|b|c]" | a b c |
Literal function | test: "@letter@" letter: "a::b::c" |
a b c |
Declaration | test: "@l<<letter@ and @l@" letter: "a::b::c" |
a and a b and b c and c |
Post-processing on literal | test: "text->capital" | Text |
Post-processing on sequence elements | test: "a::b->upper" | a B |
Post-processing on in-line sequence elements | test: "[A->lower|B] | a B |
In-line evaluation for variable naming | full-1: "one" full-2: "two" full-3: "three" |
number 1 one number 2 two number 3 three |
The language now needs a finer control of the options for each variable; doing some tests with the Proppian fables, it is immediately clear that:
- for many variables, equal probabilities do not always result in more fluent text; I will probably need to add an optional way to specify the probability of each item
- there must be a way to exclude a value from the alternatives; if for example I want to generate something like "the monster was @ugly-synonym@ and @ugly-synonym@", there should be a way to specify that I want two different synonyms for "ugly".
Regarding the language, it is true that my choice for the {...} notation is only oriented by the easiness of coding while exploring a good syntax; any decent parser should accept a nested @...@ (which is what it actually is). However, the language is starting to look "lispy", and maybe I should not reinvent the wheel (and it would be a good excuse to actually learn LISP the proper way).