-
Notifications
You must be signed in to change notification settings - Fork 143
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
Consider Rob Arthan’s “HOL Constant Definition Done Right” #72
Comments
Consider this for HOL4 on the OpenTheory mailing list as well, then OpenTheory may also adopt it (or not if it's bad). Or else someone (probably me) will write the wrappers. I wouldn't count that problem for much in the deliberation. |
Two issues with HCDDR:
|
Neither of those points are true, as far as I understand the proposed new_specification. The rule is specifically designed to depend only on one primitive constant (equality). The current form of new_specification should be derivable directly. Hmm, let me just implement it on a new branch and see. |
I misunderstood, you are right. You were talking about how to derive the existing new_specification from the proposed new one (which we could call loose_specification, just to have a different name for it), and the proposal for how to do so does indeed depend on choice and pairs. One question to consider: if loose_specification is available in Theory (implemented via a primitive in Thm), where should new_specification and new_definition be available from? Is Theory still the right place? |
It'd be ugly to have something that morally depended on pairs in |
I haven't been keeping up, but we already do something similar for Konrad. On Wed, Feb 19, 2014 at 10:57 PM, Michael Norrish
|
What about putting the backwards-compatible new_specification much later, like bossLib? Any uses of it prior to that are presumably under our control and can just be ported to loose_specification (the revised new_specification: any better name?). |
This would be fine as long as no existing uses of I think |
loose_specification permits definition of multiple constants simultaneously natively. |
Only if you have equations for them; with |
Hmm... ok. You could probably just change the MOD_DIV_exist theorem to prove existence of e.g. a function on Booleans that returns either MOD or DIV, rather than depending on pairs properly. |
Because the constants are unique, you could also define them in stages, one after the other using something like
I'm sure you'll think of something. |
Err, the exists will have to be under the scope of a forall m and n representing the arguments to the function. |
Looks like there's a more annoying use of |
Perhaps it's worth reconsidering putting the backwards-compatibility wrapper in Theory. It might be possible without pairs (but still using choice) if instead of choosing a tuple we choose a function from some appropriate powerset of booleans (since numbers aren't around either). Hmm that's probably pretty complicated though. |
The function from the booleans also assumes the constants all have the same type |
I believe this is now done. |
See http://permalink.gmane.org/gmane.comp.mathematics.hol/1555
One potential problem is that it may make OpenTheory inter-operability more difficult.
The text was updated successfully, but these errors were encountered: