runtimeverification / runtimeverification/haskell-backend

Discussion: Definedness analysis in rewrite rules and equations

Open
#3,770 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

runtimeverification/hs-backend-booster
Dominant language
Haskell
Stars
224
Forks
43
PR merge metrics
No merged PRs in 30d

Description

While discussing "argument predicates" for function rules, some questions about definedness in rule/equation side conditions came up.
This issue persists aspects of this discussion for posterity and further development.

  • Possibly one should check, in this order:
    • assuming the LHS term is defined, are the requires guaranteed to be defined?
    • assuming LHS term and requires are defined, is the RHS guaranteed to be defined?
  • if only total functions and constructors (total) are used in a term, it is safe to assume that the term is defined (safe approximation).
    • If, for example, a requires clause ends up containing a division by zero: division is not total. We should analyse requires clauses for the functions used.
  • Currently, hs-backend-booster tries to perform a safe approximation of whether a rule preserves definedness.
    • The RHS term is checked to not contain partial functions.
    • But what about RHS predicates and LHS predicates?
      • This is not a problem for rewriting in booster at the moment, as no rule gets applied unless they are all true anyway (NB that the RHS predicates are checked, too, to prune invalid states).
      • once terms are simplified inside side conditions, definedness of side conditions needs to be ensured.
        • i.e., side conditions have to be checked like the RHS term is (symbols can occur inside \equals and \in predicates)
        • Simplifications whose predicates do not preserve definedness have to be discarded.
        • If a function rule has predicates which do not ensure definedness, no rules of the same and lower priorities can be safely applied.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with hs-backend-booster's current safe approximation of definedness for rewrite rules, then trace how RHS terms, LHS predicates, RHS predicates, and requires clauses are checked. The issue does not name files or tests; done would require a settled design for definedness analysis across side conditions and simplifications.

Written by the indexing model from the issue text.

Assessment

Tech stack
haskell
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.