wz1000

rules can be evaluated in 2 modes - if the rule was previously run, then we build all of its dependencies from the previous run and then run (or skip)...

Crucially, if an earlier dependency changes, we skip speculatively building later dependencies. This prevents us from getting into conditions where rules are built when their preconditions are not met because...

For a concrete example, consider the `GetLinkable` rule, which should only be executed when the `NeedsCompilation` rule returns a `Just` value. I think the bug is that in certain cases,...

> but I am a bit worried on the performance impact on this linearity. Yes that was the concern, but we could still build all rules depended on simultaneously using...

I guess we could also just throw exceptions when preconditions are violated, and have these exceptions be caught and ignored by hls-graph. Instead of ``` error $ "called GetLinkable for...

Could you also change the following in `typecheckRule` to throw an error? ``` when (foi == NotFOI) $ logWith recorder Logger.Warning $ LogTypecheckedFOI file ``` Earlier it was very easy...

Your unit test needs to list all the modules in the arguments section of the `hie.yaml` file for `GetKnownFiles` to work.

@pepeiborra thoughts?

> It doesn't _build_ the previous dependencies, only recomputes them. This can be a no-op if the dependencies are not dirty. What is the distinction between 'build' and 'compute' here?...

> So the gist of your proposal is to not evaluate all the dependencies in parallel. Instead, evaluate them "only as much as needed", and stop as early as possible,...