PART I
Warm-up
Reconnect with a useful idea before starting types after names. 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.
A rough note is enough. You can revise it after the example.
PART II
Instruction & guided example
Test Boolean boundaries with integer inputs
A type-compatible input can sit on the exact boundary between true and false. A boundary table should show the comparison, its Boolean result and the feature interpretation. This prevents confusing the integer zero with the Boolean false as if they were the same value.
For positive(count), the body count > 0 gives false at -1, false at 0 and true at 1. The input column remains i32 in every row; the output column remains bool. Zero is not converted into false: comparing it with zero produces false.
A shop may reject negative counts before calling positive, but this helper’s shown comparison still has a clear paper result for -1. State policy separately. Do not invent a type error merely because an integer value is unsuitable for a feature.
Worked reasoning and supplied artifact
fnc positive(count: i32) -> bool {
return count > 0;
}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 positive(count: i32) -> bool {Read the function name, its parameter names/types and the result type after ->. This is the contract the body must satisfy.
return count > 0;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
Fill the -1/0/1 table and explain the exact reason equality follows the false path.
- 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.
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.
PART IV
Independent practice
Project context: Workshop stock counter. Build a small, understandable change around types after names.
For a minimum-exclusive temperature rule temperature > 5, choose the three nearest integer boundary cases and predict the Boolean result. Explain the result if the rule instead allowed equality.
What to produce
Cases 4 false, 5 false, 6 true, and an equality-policy note distinguishing > from a different requirement.
- 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.
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?
For positive(count), the body count > 0 gives false at -1, false at 0 and true at 1. The input column remains i32 in every row; the output column remains bool. Zero is not converted into false: comparing it with zero produces false.
A shop may reject negative counts before calling positive, but this helper’s shown comparison still has a clear paper result for -1. State policy separately. Do not invent a type error merely because an integer value is unsuitable for a feature.
Original learning-path task and reference
In a classroom scheduling assistant, demonstrate types after names. Add normal, boundary, and invalid-input cases and explain expected behavior. 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.
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.
- Test Boolean boundaries with integer inputs
- A type-compatible input can sit on the exact boundary between true and false. A boundary table should show the comparison, its Boolean result and the feature interpretation. This prevents confusing the integer zero with the Boolean false as if they were the same value.
- Separate source-backed behavior, host requirements and untested predictions.
One small recap task
Write the input type and result type beside the equality boundary row.
This marks your personal practice record only. It is not a certification or an official workspace assessment.