Alacrity's interact primitive should take the following explicit arguments:
An arbitrary object (typically a string) that serves as a hint for the user to input data and/or for the frontend developer to present the correct interface, or link to the correct non-interactive process (non-interactive from the point of view of the larger computation, though interactive as far as the verified blockchain DApp is concerned).
A type and/or a predicate, that represent what kind of data will be provided to the DApp; the application won't make progress unless the data provided is of the specified type and satisfies the specified predicate; if the user fails to provide satisfactory data on time, they will timeout and fail.
However, the generated code should also include an implicit argument, which is the entire reified state of the DApp, which for now consists in all variable bindings, as well as a mapping from source variable to generated variable. In the future, the state may also include control frames that recursively contain more bindings and frames, as well as heap information, etc. Thus, the frontend application or other back-program (to reuse terminology from my thesis) possesses complete context to present to the human user (or automated agent) to make an informed decision in choosing their next action.
Alacrity's
interact
primitive should take the following explicit arguments:However, the generated code should also include an implicit argument, which is the entire reified state of the DApp, which for now consists in all variable bindings, as well as a mapping from source variable to generated variable. In the future, the state may also include control frames that recursively contain more bindings and frames, as well as heap information, etc. Thus, the frontend application or other back-program (to reuse terminology from my thesis) possesses complete context to present to the human user (or automated agent) to make an informed decision in choosing their next action.