From: Peter Lammich <lammich@in.tum.de>
Hi,
a student of mine recently noticed that there is no documentation for
the "eval" method. Nevertheless, he was able to find it. What he of
course did not recognize was, that it actually seems to "prove" theorems
by cheating (they are pretty-printed with [!] afterwards).
So I propose to either add proper documentation for this method,
including a warning that it does not go through the inference kernel,
perhaps even renaming it to something like "eval_sorry", or to remove
it.
From: Lukas Bulwahn <bulwahn@in.tum.de>
Hi Peter,
A thorough documentation can be found in the code generation tutorial in
chapter 6.
If you care much about evaluations going through Isabelle's inference
kernel, Isabelle provides a method "code_simp", which does the same as
eval but slower ;)
Maybe you could add documentation about eval in the Isar reference (by
extending chapter 10.20) then, and summarize the proof methods of chapter 6?
Removing is not possible as the Flyspeck proof relies on this method.
In my opinion, renaming is not a reasonable option either.
Lukas
From: Makarius <makarius@sketis.net>
"eval_sorry" would indeed be a rather odd name, because it is based on a
different oracle that is supposed to be correct relative to the
implementation of the code generator.
In contrast, the oracle behind "sorry" merely pretends that "!!X. X"
holds, so you will be really sorry if you rely on the result.
Makarius
From: Jasmin Blanchette <jasmin.blanchette@gmail.com>
But what about "eval_oracle"? It would minimize the risk that somebody misunderstood its nature (and would free up a useful name, "eval", for the non-oracle version if desired).
Jasmin
From: Florian Haftmann <florian.haftmann@informatik.tu-muenchen.de>
»eval« is the successor of the »evaluation« method, which wasn't ever
documented thoroughly either (at least I guess so, otherwise I would
have migrated that documentation).
If all methods relying on oracles are supposed to reflect this in their
name, there are a couple of other candidates also, e.g. normalizsation.
Keep this in mind when discussing renames etc.
Florian
signature.asc
Last updated: Nov 21 2024 at 12:39 UTC