Skip to content

Add env var to disable typing of formulas during entailment checking#60

Merged
danbaterisna merged 6 commits into
masterfrom
disable-typing
Nov 10, 2025
Merged

Add env var to disable typing of formulas during entailment checking#60
danbaterisna merged 6 commits into
masterfrom
disable-typing

Conversation

@danbaterisna

Copy link
Copy Markdown
Collaborator

When the prover is run with NOTYPES=1, all types in staged formulas are replaced with Any to simplify the needed processing in situations where type inference is incomplete (e.g. when untyped extensions are present). Before SMT translation, all Anys are replaced with fresh type variables, and only then are types inferred.

Should there be a warning for when untyped extensions are used with types enabled?

this should probably only be done in untyped mode, though currently
the `can_unify_with` check eliminates all ill-typed instantiations
in typed mode so it won't change anything for now
@danbaterisna danbaterisna changed the title Add NOTYPES env var to disable typing of formulas during entailment checking Add env var to disable typing of formulas during entailment checking Sep 5, 2025
Comment thread docs/development.md

Setting `NOTYPES=1` will defer all typechecking during entailment checks until necessary (i.e. before SMT translation). This may be useful to ease development of extensions
outside of those typechecked by OCaml.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused about the intended use of this, i.e. how this eases development. Is it to disable the type checking in case there are bugs in it?

If so, why is that related to shift/reset - my understanding is that without NOTYPES, shift/reset will be typed with Anys and will still work.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it to disable the type checking in case there are bugs in it?

Yes, at least according to my interpretation. Even if shift/reset are typed with Anys, there may still be bugs inside the type checker when dealing with those Anys.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To add to this, there are cases where these Anys prevent the type checker from seeing that two types are equal. Since Any does not propagate, depending on how types are handled later on, it can be a nuisance to have to worry about types when implementing similar future extensions which do not have a simple-to-implement type system (since otherwise, rewriting rules do not match due to type mismatches, etc.)

@VietAnh1010

Copy link
Copy Markdown
Collaborator

This is fine, but is there a way to 'hide' the implementation of Dynamic_type away?

Like, we have a flag that the start, and at runtime based on this flag we will "choose" the corresponding "implementation"/"module". For the rest of the code, they should never need to know about the existent of Dynamic_type.

@danbaterisna

Copy link
Copy Markdown
Collaborator Author

I'm not sure there's a clean way to do that.

To implement this via two different "implementations" (instead of the current approach, where dynamic_typing_enabled is checked at specific places), you'd need to effectively duplicate either Hiplib or Entail.

Maybe the use_dynamic_typing_if_enabled functions can be moved to Dynamic_type? Then these places would not need to check the flag by themselves...

@danbaterisna danbaterisna merged commit 1d33775 into master Nov 10, 2025
1 check passed
@VietAnh1010 VietAnh1010 deleted the disable-typing branch March 5, 2026 06:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants