1 * MW: clarify/eliminate Isabelle/Scala add-ons (presently unused)
3 diff -r /home/makarius/isabelle/repos-Isabelle2021/src/Pure/build-jars ./src/Pure/build-jars
5 > src/Tools/isac/BridgeJEdit/isac.scala
7 diff -r /home/makarius/isabelle/repos-Isabelle2021/src/Pure/Tools/scala_project.scala ./src/Pure/Tools/scala_project.scala
9 > "src/Tools/isac/etc" -> Path.explode("isabelle.isac"),
12 ***** some items for discussion
14 * What is the idea behind KEStore_Elems.add_thes? How to do it properly in current Isabelle?
15 https://static.miraheze.org/isacwiki/0/04/Isac-docu.pdf distinguishes
16 several kinds of ISAC users, in particular "math author (Mathematik-Autor)" and
17 "course designer (Kurs-Designer)". The latter just adds examples which re-use existing
18 knowledge designed by the former. KEStore_Elems.add_thes is an interface for the latter.
19 KEStore_Elems.get_thes and KEStore_Elems.add_thes are ONLY required for the Lucas-Interpreter
20 retrieving Thm and Rls from string-identifiers (which do NOT indicate the theory of) --
21 -- get_thes and add_thes are the main reason for (b)
22 So: How can KEStore_Elems.get_thes and KEStore_Elems.add_thes be replaced in current Isabelle?
24 * Clarify symmetric rule: Thm.apply_attribute Calculation.symmetric thm context (!?);
27 * "fun pr_ord" is not required if used with @{make_string}, @{print}, @{print tracing};
28 takes only static arguments ----------------^^^^^^^^^^^^^^, not value of "hd_ord (f, g)"
29 ? are there better approximations to old output of (*1*) than with (*2*)
30 (*1*)val _ = tracing ("hd_ord (f, g) = " ^ ((pr_ord o hd_ord) (f, g)) );
31 (*2*)val _ = @{print tracing}{a = "hd_ord (f, g) = ", z = hd_ord (f, g)}(**)
33 * KEStore_Elems: Should we eliminate union_overwrite and use standard namespace merge?
34 (Exception: rlss with its special cross-theory merge.)
35 ? how adapt the different signatures ?
36 union_overwrite: ('a * 'a -> bool) -> 'a list -> 'a list -> 'a list
37 merge : ('a * 'a -> bool) -> 'a list * 'a list -> 'a list
40 ***** for the few items below WN asks MW for help
42 * MW: make Outer_Syntax.command \<^command_keyword>\<open>problem\<close> a model for ..\<open>Example\<close>
43 The model should demonstrate, how an ML syntax error is indicated in place
44 (in the string after \<^keyword>\<open>Given\<close> etc) and not on the definition as a whole.
45 - in MathEngBasic/problem "Outer_Syntax.command \<^command_keyword>\<open>problem\<close>" there are writeln
46 and comments with testdata from "problem pbl_bieg : "Biegelinien"" in Biegelinie.thy
47 - in MathEngBasic/problem there is guesswork ("TODO") how to reorganise "fun prep_input_PIDE"
48 such that errors in "Given" etc are indicated WITHIN the term.
50 * MW: In Outer_Syntax.command \<^command_keyword>\<open>Example\<close> is there a quick fix
51 for successfully replacing hacked Problem.parse_cas by parse_references_input?
52 (a) In addition to replacing Problem.parse_cas: How implement the optional parser:
53 - Example "Diff_App/No.123 a" + NONE
54 - Example "Diff_App/No.123 a" + SOME (probl_id, model_input, refs_input)
55 i.e. we expect ISAC to present an empty template "Problem..Solution", but as a whole, to the user;
56 see VSCode_Example.thy subsubsection \<open>Specification step by step\<close>
57 How get Token.src for testing purposes?
58 How can Scan.* be traced?
59 (Tracing should help understanding Problem.parse_cas, Problem.parse_model_input which involve Scan.* )
61 * ?How represent items, which have not yet been input?
62 Note: For the purpose of user-guidance the format of requested input should be indicated!
63 - proposal for how to indicate requested input: in VSCode_Example.thy subsubsection \<open>Empty Specification>
64 - the trial with <fun is_empty> in Calculation.thy makes the question more precise:
65 better hack parsers or better work on ML_Syntax?
68 ***** priority of WN items is top down, most urgent/simple on top
70 * WN: rewriting with ctxt not complete (cause errors hard to indentify later)
72 - Solve_Step.check ..Rewrite_Inst, Substitute, ..
73 - Error_Pattern.check_for', fill_form
75 - Fetch_Tacs.specific_from_prog ?
76 - Eval.adhoc_thm, adhoc_thm1_
77 - ? LIST IS NOT COMPLETE
79 * WN: proper ML antiquotations for "Tactical.Try" etc. --- be careful about unclear situations,
80 e.g. "Tactical.Try" vs. "Lucas_Interpreter.Try";
82 * WN: ? Rational.Cancel_p; extend use of \<^theory> to \<^theory_context>
84 * WN: Avoid Thm.get_name_hint and use Global_Theory.get_thm instead, get theory from References.T
85 and push theory through as argument of respective functions.
87 * WN: Eliminate Thy_Info.get_theory eventually: should take theory from ancestory
88 within current context.
89 cf. e587c45cae0f note in Build_Thydata.thy
91 * WN: Check/clarify Context.theory_name vs. Context.theory_long_name.
92 present ISAC assumes 2 sessions in the MathEngine, Specify and Interpret,
93 and all Isac_Knowledge is in session Isac.
94 So Context.theory_name suffices
96 * WN: more direct logical foundations wrt. Isabelle/HOL, eliminate many axiomatizations
97 - quite often "axiomatization ..." can be turned into "lemma ... by auto"
99 - sometimes this requires to use more specific types / type classes;
100 - sometimes this requires to use proper definitional mechanisms (e.g. 'primrec', 'fun');
101 - a few "hard" cases will remain, to be reconsidered eventually (e.g. differentiation);
103 * WN: redesign transition from Specification to Solution: how relate
104 - Formalise.model with variants (e.g. VSCode_Example)
105 reconsider separation of variants F_I, F_II, see MAWEN paper
106 - !?! I_Model of MethodC (fairly free sequence, dependent on Formalise.model)
107 - !?! formal arguments of program (fixed sequence)