Check that the code is wired as the graph plans - #11
Merged
Merged
Conversation
A review from the agent's side found ways a wrong implementation, or a
spec that says less than it seems to, got through:
- a spec helper named like a target fn was replaced by the target's, so
a law judged the code with the code and was "proved"; that is now an
error naming the helper to rename
- edges only bounded the code: a signal stuck on green kept every edge.
Each target of an edge is now also a law that some value takes the step
- two states of one plain type told nothing apart, so the sort's
:unsorted -> :sorted edge checked only a list type; that fails now, and
the edge into a refinement is the law. An edge mixing a plain target
with refined ones fails for the same reason
- a public fn with no ann passed unchecked; it fails now, and the report
lists signed public fns no graph, machine or flow names
New forms: `flow` states the path data takes through a fn and is checked
by following values through its lowered source; `calls` takes
{:through [..] :not [..]} for reach on the transitive graph; both accept
a fn of another namespace, so an effect shell's wiring can be stated.
An edge may place its state with `_` and take a state out of a tuple with
first/second/last. `spec/plan` prints the spec as a plan a person can
confirm before code exists, and `mermaid` draws a graph.
Edge laws are written as the target's predicate of the call, and when
"never throws" can't be proved for a recursive fn the landing is proved
anyway and the report says totality was tested. A law that says the same
as a proved one is proved by it when no proof from the code is found.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A review of writ from the agent's side, where a spec is the plan and the check confirms the code follows it, found ways wrong code or a weaker-than-it-looks spec got through (writ-sg8).
Fixed:
sortedproved. That is now an error naming the helper to rename:unsorted -> :sortedover(List Nat)checked only the type. That fails now; the fix is a refinement, and the edge into it becomes the law. An edge mixing a plain target with refined ones fails tooNew:
flowstates the path data takes through a fn,(flow handle [s] [s normalize respond :result]), checked by following values through its lowered source (lambdas, fns passed by name, loops). It catches code that calls every layer but hands one the raw inputcallstakes{:through [..] :not [..]}, checked on the transitive graph and reported with the pathcallsandflowaccept a fn of another namespace, so an effect shell's wiring can be stated; the shortener spec now pinsshortener.server/apptocore/handlethrough the store. The shell is read, never loaded_([insert Nat _]) and take a state out of a tuple with first/second/lastspec/planprints the spec as a plan to confirm before code exists;mermaiddraws a graphProver side: edge laws are written as the target's predicate of the call, so they're proved like the spec's own laws. "Never throws" is only provable symbolically, which recursion defeats, so for recursive fns the landing is proved and the report says totality was tested. A law that says the same as a proved one is proved by it when no proof from the code turns up.
Many demo specs used the two-plain-states graph, several claiming insert into any list is sorted; they now use a
Sortedrefinement, and some law counts in tests grew with the new edge laws.writ tests: 392 pass. Examples: all pass; shortener takes 390s against 399s on main.