Fine-tuning the design of feedback

[countvajhula]

User 1e1001 brought up in the inaugural Design Challenge that it would be convenient if the feedback form could accept the N parameter as a flow input. More generally, they pointed out that there are cases where some of the flows are unchanged across iterations, and it would be nice not to have to feed these back in each time.

Two key things identified here:

A. The number of times to feed back (vs feeding back based on a while condition) is awkward to use in some cases
B. Managing unchanging parameters in the feedback specification seems unnecessary

Questions to answer:

1. Regarding (A) above, is there ever a case where we cannot provide this information syntactically? E.g. as (feedback 3 ...)
2. Re: (B), can such unchanging parameters always be provided syntactically?

My suspicion is that for (1), the answer is no, and for (2) the answer is yes. [Input needed: Do you agree with these answers? Also see below for more re: the rationale for the ability to modify these parameters at runtime]

Assuming the answers above are borne out, then we could formalize the design of the feedback form this way:

1. It should be possible to provide any subset of feedback parameters syntactically. That is, all of these should be accepted as valid:

(feedback N)
(feedback N flo)
(feedback N (then then-flo))
(feedback N (then then-flo) flo)
(feedback (while cond-flo))
(feedback (while cond-flo) flo)
(feedback (while cond-flo) (then then-flo))
(feedback (while cond-flo) (then then-flo) flo)

2. In all of these cases, if any of the parameters are not specified syntactically, then they must be provided as runtime inputs. These inputs will be expected in a standard order: the while condition (cond-flo), the final transformation (then-flo), the actual recursive flow (flo), followed by the data inputs.

3. If no parameters are specified syntactically,

feedback

... then the first input will be expected to be cond-flo (and not N), since the while condition is after all more general, and could model the N case if needed. Arguably if we are modifying this parameter at runtime -- already perhaps unusual behavior -- then the need for the modulating the former is less conceivable than the latter, and so the latter could be more practically useful. But it's hard to design for such cases without practical examples to work with (and the former preserves backwards compatibility so there would need to be a concrete reason to change it).

Now, to be honest, I don't really recall the motivation for the ability to modify parameters (e.g. cond-flo) at runtime to begin with, but at least, it's a pattern that doesn't overlap with the syntactic usecases, so there's no harm in supporting both until we can find out whether it is truly more expressive in some way, or not. It does seem interesting that you can essentially write parts of the program at runtime by providing flow inputs, but I'm not quite sure what to make of it. Edit: The reason for accepting parameters as runtime or "control" inputs is that this is an alternative to having bindings. That is, we are able to leverage Racket's bindings at the top level of a flow specification, via e.g. define, let or even (define-flow (v ...) ...), but we cannot use these to give names to derived values that are produced at intermediate stages of a flow. Qi does not currently offer a way to produce bindings "natively." The options here are to either decompose flows into components whose outputs are named (using Racket definition forms), or to parametrize forms using the "control" inputs. This does mean the answer to (1) above is yes - there are cases where flow parameters cannot be specified syntactically, and would require the use of runtime "control" inputs. But the only thing this affects in the design is the pure identifier form, feedback, and whether that should accept a while condition or a number.