Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with three nominal types #1418

Open
binghe opened this issue Mar 4, 2025 · 2 comments · May be fixed by #1421
Open

Issue with three nominal types #1418

binghe opened this issue Mar 4, 2025 · 2 comments · May be fixed by #1421

Comments

@binghe
Copy link
Member

binghe commented Mar 4, 2025

Thanks for the fix of #1414. Unfortunately I totally need three nominal types and the 2nd and 3d both have no GVAR constructors. In this case, the call of new_type_step1 still fails. The following code is a modified version of your newly added selftest.sml:

open HolKernel Parse boolLib
open pred_setTheory generic_termsTheory binderLib nomsetTheory nomdatatype
open testutils

val tyname0 = "name";
val tyname1 = "pi";
val tyname2 = "residual";

val gvar_rep_t = “:unit”;
val u_tm = mk_var("u", gvar_rep_t);
val vp = “(\n ^u_tm. n = 0)”;

val glam_rep_t = “:unit + unit”;
val d_tm = mk_var("d", glam_rep_t);
val lp =
  “(\n ^d_tm tns uns.
     n = 1 /\ ISL d /\ tns = [] ∧ uns = [] \/
     n = 1 /\ ISR d /\ tns = [1] ∧ uns = [0] \/
     n = 2 /\ ISL d /\ tns = [] ∧ uns = [0]
    )”;

val _ = tprint "Deriving type 0"
val _ = require (check_result (K true))
                (new_type_step1 tyname0 0)
                {vp = vp, lp = lp}

val _ = tprint "Deriving type 1"
val _ = require (check_result (K true))
                (new_type_step1 tyname1 1)
                {vp = vp, lp = lp}

val _ = tprint "Deriving type 2"
val _ = require (check_result (K true))
                (new_type_step1 tyname2 2)
                {vp = vp, lp = lp}

However, if the 3rd type do not use the previous two types, e.g. n = 2 /\ ISL d /\ tns = [] ∧ uns = [], then the function call of new_type_step1 will succeed.

--Chun

@binghe
Copy link
Member Author

binghe commented Mar 4, 2025

Another way to workaround the issue is to add back the GVAR constructor for the 3rd type: val vp = “(\n ^u_tm. n = 0 \/ n = 2)”

@mn200
Copy link
Member

mn200 commented Mar 4, 2025

The issue is that the third type doesn't have a base-case at all in some sense. I think the way to handle this is enrich the new_type_step1 API so that you can optionally provide theorems asserting that the previous types are inhabited. Then, the proof that the code attempts can appeal to those theorems if necessary.

binghe added a commit to binghe/HOL that referenced this issue Mar 7, 2025
…us (as a sample application).

This commit also fixes HOL-Theorem-Prover#1418 (@mn200's work).
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 a pull request may close this issue.

2 participants