Arguments

IT is a truth universally acknowledged, that a formal language after its very first drafts must be in want of arguments. But arguments, with the common syntax of Algol-derived languages, would not fit naturally in the system I am developing. I considered using parentheses and the like, but by some trial-and-error the most organic option seemed to be an adaptation of my previous Tzara engine (in turn, "heavily inspired" by the Postmodern Generator).

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	test: "num @my_n<<num@ @full-{my_n}@" num: "1::2::3" 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).