State changes with vary — Change one requirement

PART I

Warm-up

Reconnect with a useful idea before starting state changes with vary. In one or two sentences, describe the input, output or host boundary from the previous exercise that this lesson builds on. If you are arriving directly, skim the worked example first; there is no locked prerequisite.

Recall note

A rough note is enough. You can revise it after the example.

PART II

Instruction & guided example

Insert an update at the intended point

A changed requirement may introduce a new state transition. Its location should express the intended sequence, even when addition alone happens to give the same final result in another order. Intermediate values may later feed a decision or display.

The worked helper starts count 5, applies delivery 4 to reach 9, then a correction -2 to reach 7. Adding a second delivery 3 between those updates produces 5 → 9 → 12 → 10. Record the new intermediate 12 rather than updating only the final answer.

Changing the initial value from 5 to 8 also produces final 10 in this particular sequence, but it tells a different history. If the initial count is a measured input, rewriting it to hide a new event destroys useful evidence about what happened.

Worked reasoning and supplied artifact

fnc revisedCount() -> i32 {
    vary count: i32 = 5;
    count += 4;
    // New delivery belongs here: count += 3;
    count += -2;
    return count;
}

Illustrative example from the proposed WillowScript design. The language and WUIX/WMATH/WDB/WAUDIO/WTMP services are not implemented in the supplied source. This site has no interpreter, VM or native host and does not execute or certify the snippet.

Walk through the example, one line at a time

fnc revisedCount() -> i32 {
Read the function name, its parameter names/types and the result type after ->. This is the contract the body must satisfy.
vary count: i32 = 5;
Introduce a binding intended to change. Identify its initial value now so later updates can be traced rather than guessed.
count += 4;
Read the current value, add the right-hand amount and store the new value. A before/after trace makes the state change visible.
// New delivery belongs here: count += 3;
This comment explains intent for a reader. It is not an operation and should not be counted as an executed result.
count += -2;
Read the current value, add the right-hand amount and store the new value. A before/after trace makes the state change visible.
return count;
Evaluate the following expression using the current values, then send its result to the caller. Explain the value; do not confuse it with printed output.
}
Close the nested block or value begun earlier. Match it to its opening boundary to keep the structure readable.

Try the guided change

Activate the new delivery and extend the ledger with its own row. Keep the initial count unchanged.

Write the supplied inputs and initial state before following the example.
Reconstruct each intermediate calculation or host decision, then compare with the worked artifact.
Explain why the contrasting alternative fails before attempting the changed inputs in Part IV.

Prediction or guided notes

PART III

Take a breather

Step back after the guided example. Look away from the screen, stretch, or reread your prediction. This is an optional learning pause, not a timer or an assessment gate.

When you return, try to name the lesson’s key idea without copying its wording. If that feels difficult, return to Part II and trace one line rather than restarting the entire lesson.

Your drafts remain here. Continue whenever you are ready.

PART IV

Independent practice

Project context: Workshop stock counter. Build a small, understandable change around state changes with vary.

An inventory sequence starts 12, receives 8, then corrects -3. Add a 5-unit delivery before correction. Write old and new ledgers and explain why changing initial stock would misdescribe the input history.

What to produce

Old 12 → 20 → 17 and new 12 → 20 → 25 → 22 ledgers, plus the inserted source statement.

State the intended behavior in a sentence before editing.
Use only source-backed syntax and the host services whose contract you have been given.
Record a normal case and a boundary or unavailable-resource case.
Label hand predictions separately from anything actually measured in a supplied toolchain.

Your .ws practice draft

Syntax colors are a reading aid, not a compiler. The line you are editing stays uncolored until you move to a different line; capitalization is never changed. Drafts stay on this browser and code is not executed.

Need a hint?

Original learning-path task and reference

In a classroom scheduling assistant, demonstrate state changes with vary. Adapt the task to a second host-neutral application context without changing the imported API contract. Include .ws source and a host-resource contract; compare at least one normal case and one edge case.

fnc total() -> i32 {
    vary count: i32 = 1;
    const bonus: i32 = 2;
    count += bonus;
    return count;
}

Where the original task needs a host API that is not supplied here, write the contract and predictions. Do not invent a runtime result.

PART V

Self-check

Use this check to notice what to revisit. It does not award a private course grade, block another page or claim to verify compiled code. Every answer has a learning explanation.

Which edit preserves the original initial measurement while adding the new delivery?Insert a separate += 3 transitionChange the initial count from 5 to 8Delete the correction and alter the return literal

Explain a normal or boundary case

You may keep exploring even if you are unsure. Use the hint, compare the trace, and revise your explanation.

PART VI

Recap & small task

Bring the idea back to the mod feature you are building. A useful recap connects the mechanism to a decision you can make in your own code.

Insert an update at the intended point
A changed requirement may introduce a new state transition. Its location should express the intended sequence, even when addition alone happens to give the same final result in another order. Intermediate values may later feed a decision or display.
Separate source-backed behavior, host requirements and untested predictions.

One small recap task

Name the new intermediate value in the worked sequence.

Your recap

This marks your personal practice record only. It is not a certification or an official workspace assessment.