1 * MW: make Outer_Syntax.command \<^command_keyword>\<open>problem\<close> a model for ..\<open>Example\<close>
2 An ML syntax error should be indicated in place (in the string after \<^keyword>\<open>Given\<close> etc)
3 and not on the definition as a whole.
4 This however is not the case despite there is no ISAC code involved.
5 Reproducible e.g. at https://hg.risc.uni-linz.ac.at/wneuper/isa/file/9c2e1efe5cde/src/Tools/isac/Knowledge/Biegelinie.thy#l108
6 The respective improvement would be the model for WN continuing ..\<open>Example\<close>.
8 * ?MW?: In Outer_Syntax.command \<^command_keyword>\<open>Example\<close> is there a quick fix
9 for successfully replacing hacked Problem.parse_cas by parse_references_input?
10 How can Scan.* be traced?
11 (Tracing should help understanding Problem.parse_cas, Problem.parse_model_input which involve Scan.*)
13 * MW: check uses of Unsynchronized.ref vs. Synchronized.var;
15 * MW: clarify/eliminate Isabelle/Scala add-ons (presently unused)
17 diff -r /home/makarius/isabelle/repos-Isabelle2021/src/Pure/build-jars ./src/Pure/build-jars
19 > src/Tools/isac/BridgeJEdit/isac.scala
21 diff -r /home/makarius/isabelle/repos-Isabelle2021/src/Pure/Tools/scala_project.scala ./src/Pure/Tools/scala_project.scala
23 > "src/Tools/isac/etc" -> Path.explode("isabelle.isac"),
25 * Eliminate Thy_Info.get_theory eventually: should take theory from ancestory
26 within current context.
27 cf. e587c45cae0f note in Build_Thydata.thy
29 * Clarify symmetric rule: Thm.apply_attribute Calculation.symmetric thm context (!?);
32 * KEStore_Elems: Should we eliminate union_overwrite and use standard namespace merge?
33 (Exception: rlss with its special cross-theory merge.)
34 ? how adapt the different signatures ?
35 union_overwrite: ('a * 'a -> bool) -> 'a list -> 'a list -> 'a list
36 merge : ('a * 'a -> bool) -> 'a list * 'a list -> 'a list
38 * What is the purpose of "#numeral" instead of plain numeral?
41 * Check/clarify Context.theory_name vs. Context.theory_long_name.
42 present ISAC assumes 2 sessions in the MathEngine, Specify and Interpret,
43 and all Isac_Knowledge is in session Isac.
44 So Context.theory_name suffices
46 * Eliminate mutable Rewrite_Ord.rew_ord' (!?);
47 shall be done in connection with cf. e587c45cae0f note in Build_Thydata.thy
49 * What is the idea behind KEStore_Elems.add_thes? How to do it properly in current Isabelle?
50 https://static.miraheze.org/isacwiki/0/04/Isac-docu.pdf distinguishes
51 several kinds of ISAC users, in particular "math author (Mathematik-Autor)" and
52 "course designer (Kurs-Designer)". The latter just adds examples which re-use existing
53 knowledge designed by the former. KEStore_Elems.add_thes is an interface for the latter.
55 * WN: proper ML antiquotations for "Tactical.Try" etc. --- be careful about unclear situations,
56 e.g. "Tactical.Try" vs. "Lucas_Interpreter.Try";
58 * WN: Avoid Thm.get_name_hint and use Global_Theory.get_thm instead, get theory from References.T
59 and push theory through as argument of respective functions.
61 * WN: more direct logical foundations wrt. Isabelle/HOL, eliminate many axiomatizations
62 - quite often "axiomatization ..." can be turned into "lemma ... by auto"
64 - sometimes this requires to use more specific types / type classes;
65 - sometimes this requires to use proper definitional mechanisms (e.g. 'primrec', 'fun');
66 - a few "hard" cases will remain, to be reconsidered eventually (e.g. differentiation);
68 * WN: "fun pr_ord" is not required if used with @{make_string}, @{print}, @{print tracing};
69 takes only static arguments ----------------^^^^^^^^^^^^^^, not value of "hd_ord (f, g)"
70 ? are there better approximations to old output of (*1*) than with (*2*)
71 (*1*)val _ = tracing ("hd_ord (f, g) = " ^ ((pr_ord o hd_ord) (f, g)) );
72 (*2*)val _ = @{print tracing}{a = "hd_ord (f, g) = ", z = hd_ord (f, g)}(**)
75 * WN: eliminate global flags like "trace_on", replace Unsynchronized.ref by
78 val rewrite_trace = Attrib.setup_config_bool \<^binding>\<open>rewrite_trace\<close> (K false);
81 * WN: redesign transition from Specification to Solution: how relate
82 - Formalise.model with variants (e.g. VSCode_Example)
83 reconsider separation of variants F_I, F_II, see MAWEN paper
84 - !?! I_Model of MethodC (fairly free sequence, dependent on Formalise.model)
85 - !?! formal arguments of program (fixed sequence)