Propellor.Types.ResultCheck

Documentation

data UncheckedProperty i

This is a Property but its Result is not accurate; in particular it may return NoChange despite having made a change.

However, when it returns MadeChange, it really did make a change, and FailedChange is still an error.

Instances

TightenTargets UncheckedProperty

Defined in Propellor.Types.ResultCheck

Methods

tightenTargets :: (NotSuperset (Targets untightened) (Targets tightened) ~ CanCombine, NotSuperset (NonTargets tightened) (NonTargets untightened) ~ CanCombine, SingI tightened) => UncheckedProperty (MetaTypes untightened) -> UncheckedProperty (MetaTypes tightened)

Checkable UncheckedProperty i

Defined in Propellor.Types.ResultCheck

Methods

checkedProp :: UncheckedProperty i -> Property i

preCheckedProp :: UncheckedProperty i -> Property i

unchecked :: Property i -> UncheckedProperty i

Use to indicate that a Property is unchecked.

checkResult

Arguments

:: (Checkable p i, LiftPropellor m)

=> m a

Run before ensuring the property.

-> (a -> m Result)

Run after ensuring the property. Return MadeChange if a change was detected, or NoChange if no change was detected.

-> p i

-> Property i

Checks the result of a property. Mostly used to convert a UncheckedProperty to a Property, but can also be used to further check a Property.

check :: (Checkable p i, LiftPropellor m) => m Bool -> p i -> Property i

Makes a Property or an UncheckedProperty only run when a test succeeds.

class Checkable p i

Minimal complete definition

checkedProp, preCheckedProp

Instances

Checkable Property i

Defined in Propellor.Types.ResultCheck

Methods

checkedProp :: Property i -> Property i

preCheckedProp :: Property i -> Property i

Checkable UncheckedProperty i

Defined in Propellor.Types.ResultCheck

Methods

checkedProp :: UncheckedProperty i -> Property i

preCheckedProp :: UncheckedProperty i -> Property i

assume :: Checkable p i => p i -> Result -> Property i

Sometimes it's not practical to test if a property made a change. In such a case, it's often fine to say:

someprop `assume` MadeChange

However, beware assuming NoChange, as that will make combinators like onChange not work.