Build.SelfTracking

This module defines two different strategies of self-tracking, based around the idea of storing task descriptions that can be parsed into a Task.

• For Monad it works out beautifully. You just store the rule on the disk, and depend on it.
• For Applicative, we generate a fresh Task each time, but have that Task depend on a fake version of the rules. This is a change in the Task, but it's one for which the standard implementations tend to cope with just fine. Most applicative systems with self-tracking probably do it this way.

Documentation

data Key k

We assume that the fetch passed to a Task is consistent and returns values matching the keys. It is possible to switch to typed tasks to check this assumption at compile time, e.g. see Build.Task.Typed.

Constructors

Key k

KeyTask k

data Value v t

Constructors

Value v

ValueTask t

selfTrackingM :: forall k v t. (t -> Task Monad k v) -> Tasks Monad k t -> Tasks Monad (Key k) (Value v t)

A model for Monad, works beautifully and allows storing the key on the disk.

selfTrackingA :: (t -> Task Applicative k v) -> (k -> t) -> Tasks Applicative (Key k) (Value v t)

The applicative model requires every key to be able to associate with its environment (e.g. a reader somewhere). Does not support cutoff if a key changes.