bug: second sequential when in a profile silently re-scopes earlier actions under the new condition #30

Closed
opened 2026-06-11 15:38:22 +02:00 by yorunikakeru · 0 comments
Owner

DSL.Builder.when` (src/DSL/Builder.hs:74-78) overwrites `ssCondition` on the accumulated section state and keeps already-collected actions:

profile "p" $ do
  when condA $ disable "docker"   -- state: cond=A, actions=[disable docker]
  when condB $ disable "bluetooth" -- state: cond=B (A discarded!), actions=[disable docker, disable bluetooth]

Result: ProfileSection with condition B and both actions — `disable "docker"` is now silently gated on condB, condA vanishes. Same family as closed #23 (nested when), but the nested case is now a type error via scopes while the sequential case still type-checks and miscompiles intent.

BuilderSpec has no test with two `when` calls in one profile.

Fix options:

  • error in `when` if `ssCondition` is already `Just` (fail-fast, matches Builder philosophy), or
  • make profile hold `[(Maybe Condition, [Action])]` groups so each when scopes only its own body (bigger IR change).

First option is the minimal correct one.

DSL.Builder.when\` (src/DSL/Builder.hs:74-78) overwrites \`ssCondition\` on the accumulated section state and keeps already-collected actions: ```haskell profile "p" $ do when condA $ disable "docker" -- state: cond=A, actions=[disable docker] when condB $ disable "bluetooth" -- state: cond=B (A discarded!), actions=[disable docker, disable bluetooth] ``` Result: ProfileSection with condition B and **both** actions — \`disable "docker"\` is now silently gated on condB, condA vanishes. Same family as closed #23 (nested when), but the nested case is now a type error via scopes while the *sequential* case still type-checks and miscompiles intent. BuilderSpec has no test with two \`when\` calls in one profile. Fix options: - error in \`when\` if \`ssCondition\` is already \`Just\` (fail-fast, matches Builder philosophy), or - make profile hold \`[(Maybe Condition, [Action])]\` groups so each when scopes only its own body (bigger IR change). First option is the minimal correct one.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
FrogOS/DSL#30
No description provided.