Output Token Generation Capability | Program Repairing

[akibzaman]

Hello. I am working on a program repairing project using your platform. In the paper, it is written as follows:

The TOCOPO output can be intuitively viewed as a script that describes the task output in terms of tokens, drawn from the output vocabulary, and pointers pointing to some input node, concluding with a DONE token marking the end of the output. Every task can make its own use of these facilities to express a grammar for its output. For example, a classification task can use token outputs, one per expected class; a sequence-prediction task can produce a sequence of tokens; a repair task can use a pointer to point at a particular input node, and a token output to replace that input node.

My query is regarding the highlighted line. Can the output handle the occurrence of multiple errors in an input node i.e. can it produce multiple tokens to handle the errors? or is it limited to a single token per node only? Can you highlight this point?

[dan-zheng]

Not an author of the PLUR paper, but can help answer:

...; a repair task can use a pointer to point at a particular input node, and a token output to replace that input node.

Can the output handle the occurrence of multiple errors in an input node i.e. can it produce multiple tokens to handle the errors? or is it limited to a single token per node only? Can you highlight this point?

If I understood your question: yes – though not explicitly shown in the PLUR paper, the Tocopo (token-copy-pointer) formulation is flexible and can support multiple output tokens per output pointer. For example, the INSERT_BEFORE Tocopo actino has the following format: INSERT_BEFORE <pointer> token_0 ... token_n.

Figure 1 shows an example RENAME Tocopo action. The payload of the RENAME action is shown as just "x", but could actually be multiple tokens (e.g. from a subtokenized vocbulary).

---

Learning to Fix Build Errors with Graph2Diff Neural Networks (cited by the PLUR paper) introduced the idea of Tocopo and goes into more detail about what Tocopo sequences look like: see figures 3 and 6.

[nashid]

@dan-zheng, I think the question asks what would happen if the model's output needs to represent multiple edits. Let's say:

Buggy Code: foo(a, b) Correct Code: foo(a, c, d)

For this example, instead of b we can output c, d, which would be allowed by the Tocopo grammar.

However, what would happen if the edit is in multiple locations? The syntax would not support multi-location edits. Could we extend the model for multi-statement (i.e. multi-hunk) repair?

To summarize:

• single location, multiple edits: supported by the model.
• multi-location repair: not supported.

[dan-zheng]

@nashid Thanks for clarifying the question!

Multiple edit locations are supported via multiple INSERT actions.

# Input code:
foo(a, b)

# Tokens (enumerated):
[(0, 'foo'), (1, '('), (2, 'a'), (3, ','), (4, ' '), (5, 'b'), (6, ')')]

# Target code:
foo(a, HelloWorld, d)

# Example Tocopo repair:
INSERT_BEFORE POINTER(5) 'Hello' 'World' ','
RENAME POINTER(5) 'd'
DONE

In general, Tocopo sequences (i.e. "Tocopo scripts" or "Tocopo repairs") are keyword-prefixed actions (INSERT_BEFORE, DELETE, etc) whose arguments are an action-specific and action-defined mix of tokens, copies, and pointers. The specific Tocopo actions can be designed per task.

Does this help answer your question?