eta.core.execution
The core process responsible for executing primitive actions and matching expected events.
Functions
Execute a store-in-STM step. |
|
Execute a say-bye step. |
|
Execute a say-to step. |
|
Execute a store-in-STM step. |
|
Either execute the current intended step of the plan or attempt to match an expectation. |
|
Characterize the current step as a failure using a special 'no-op' predicate. |
|
Attempt to match an expected event to a fact in context. |
|
Process a condition step by advancing only if none of the condition are true. |
|
Process an expected step by failing it if the waiting period has elapsed, or matching it to a fact in context. |
|
Process an intended step by attempting to map it to a primitive action to execute. |
|
Process a repetition step by advancing only if the condition is satisfied. |
|
- execution_loop(ds)[source]
Either execute the current intended step of the plan or attempt to match an expectation.
This will do one of several things depending on the class of the currently pending step:
If a condition or repetition step, advance the plan once none of the conditions are true.
If an expected step, attempt to match the step to a fact in context, until a time period based on the certainty of that step has elapsed, in which case the step is characterized as a failure and the plan is advanced.
If an intended step that contains a primitive action, attempt to execute that action, and advance the plan if successful.
In any the case where an execution or match is successful, the plan is advanced, and a list of variable bindings obtained from the execution or match is applied throughout the dialogue state. Additionally, if the plan was advanced, the contents of the ‘plans’ buffer is replaced with the modified plan.
Note that, if the plan wasn’t advanced but the step is a condition or repetition step, the plan is still added to the ‘plans’ buffer, but only if currently empty. This is because the condition may change with any observation, so the planning loop must constantly check for possible expansions of that step.
- Parameters:
ds (DialogueState) –
- process_condition_step(event, ds)[source]
Process a condition step by advancing only if none of the condition are true.
- Parameters:
event (Condition) – The condition step to process.
ds (DialogueState) –
- Returns:
Whether to advance the plan.
- Return type:
- process_repetition_step(event, ds)[source]
Process a repetition step by advancing only if the condition is satisfied.
- Parameters:
event (Repetition) – The repetition step to process.
ds (DialogueState) –
- Returns:
Whether to advance the plan.
- Return type:
- process_expected_step(event, ds)[source]
Process an expected step by failing it if the waiting period has elapsed, or matching it to a fact in context.
Since an expected user step indicates the user’s dialogue turn, we also write the current output buffer at this point.
The dialogue context is flushed of “telic” predicates, i.e., those assumed to be essentially instantaneous, after a successful match (we assume that such predicates may only be used once in a match before becoming outdated).
- Parameters:
event (Eventuality) – The expected step to process.
ds (DialogueState) –
- Returns:
Whether to advance the plan.
- Return type:
- inquire_truth_of_curr_step(event, ds)[source]
Attempt to match an expected event to a fact in context.
If a match is successful, this will bind all variables unified in the match throughout the dialogue state.
- Parameters:
event (Eventuality) – The expected step to attempt to match.
ds (DialogueState) –
- Returns:
Whether the match was successful.
- Return type:
- fail_curr_step(event, ds)[source]
Characterize the current step as a failure using a special ‘no-op’ predicate.
- Parameters:
event (Eventuality) – The expected step to fail.
ds (DialogueState) –
- Returns:
Whether to advance the plan.
- Return type:
- process_intended_step(event, ds)[source]
Process an intended step by attempting to map it to a primitive action to execute.
If an action was successfully executed, the action returns variable bindings that are then applied throughout the dialogue state.
- Parameters:
event (Eventuality) – The expected step to fail.
ds (DialogueState) –
- Returns:
Whether to advance the plan.
- Return type:
- execute_say_to(step, ds)[source]
Execute a say-to step.
This will create a response and affect using the corresponding transducers, as well as potentially deriving a gist clause and semantic interpretation from the response. Any obligations are retrieved from the step as well. The resulting dialogue turn is added to the conversation log and pushed onto the output buffer.
- Parameters:
step (PlanStep) – The say-to step to execute.
ds (DialogueState) –
- Returns:
Dict of variable bindings obtained in the course of execution.
- Return type:
- execute_say_bye(step, ds)[source]
Execute a say-bye step.
This will signal that the conversation should be ended immediately, setting the quit_conversation flag to True in the dialogue state and writing the remaining output buffer.
- Parameters:
step (PlanStep) – The say-to step to execute.
ds (DialogueState) –
- Returns:
Dict of variable bindings obtained in the course of execution.
- Return type:
- execute_store_in_STM(step, ds)[source]
Execute a store-in-STM step.
This will store a given fact in short-term memory (i.e., context).
- Parameters:
step (PlanStep) – The say-to step to execute.
ds (DialogueState) –
- Returns:
Dict of variable bindings obtained in the course of execution.
- Return type:
- execute_forget_from_STM(step, ds)[source]
Execute a store-in-STM step.
This will remove a given fact in short-term memory (i.e., context).
- Parameters:
step (PlanStep) – The say-to step to execute.
ds (DialogueState) –
- Returns:
Dict of variable bindings obtained in the course of execution.
- Return type: