Presently generators annotated on a PADS description get executed (in do-notation-style?) in the order in which they are defined in the description, that is in parsing-order. This makes context-sensitive generators (generators that rely on the value of some other field of the data type) cumbersome because fields can only refer to each other when the reference occurs after (in the file) the referent.
What needs to be done: in the initial step of generating the dataType_genM, we need to do a topological sort of the fields of the data type, where fieldA < fieldB iff the generator for fieldA does not refer in any way to the variable name fieldB. Then the do-notation generator which brings names into scope in the order in which they are generated will function properly (as expected).
An error message must be produced if a topological sort does not exist (cycle dependency)
This feature will interact with generator support for the state monad, namely changing the order in which things are generated will change the behavior of generators which rely on StateT. Therefore some canonical ordering should be chosen (perhaps prefer keeping the default ordering, and only swapping when one generator computation is dependent on the other).
cronburg
commented
5 years ago
Presently generators annotated on a PADS description get executed (in do-notation-style?) in the order in which they are defined in the description, that is in parsing-order. This makes context-sensitive generators (generators that rely on the value of some other field of the data type) cumbersome because fields can only refer to each other when the reference occurs after (in the file) the referent.
What needs to be done: in the initial step of generating the
dataType_genM, we need to do a topological sort of the fields of the data type, wherefieldA < fieldBiff the generator forfieldAdoes not refer in any way to the variable namefieldB. Then the do-notation generator which brings names into scope in the order in which they are generated will function properly (as expected).StateT. Therefore some canonical ordering should be chosen (perhaps prefer keeping the default ordering, and only swapping when one generator computation is dependent on the other).