TODO.md
author wneuper <Walther.Neuper@jku.at>
Sat, 23 Jul 2022 20:05:25 +0200
changeset 60487 28da4f69d32d
parent 60485 c14f2538095c
child 60492 a4f173bee704
permissions -rw-r--r--
//continued: investigate Outer_Syntax.command \<^command_keyword>?problem?
     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     - in MathEngBasic/problem "Outer_Syntax.command \<^command_keyword>\<open>problem\<close>" there are writeln
     5       and comments with testdata from "problem pbl_bieg : "Biegelinien"" in Biegelinie.thy
     6     - in BridgeJEdit/Calculation.thy are remainings of time-consuming investigations
     7     - in MathEngBasic/problem there is guesswork ("TODO") how to reorganise "fun prep_input_PIDE"
     8       such that errors in "Given" etc are indicated WITHIN the term.
     9 
    10 * ?MW?: In Outer_Syntax.command \<^command_keyword>\<open>Example\<close> is there a quick fix
    11   for successfully replacing hacked Problem.parse_cas by parse_references_input?
    12     How get Token.src for testing purposes?
    13     How can Scan.* be traced?
    14     (Tracing should help understanding Problem.parse_cas, Problem.parse_model_input which involve Scan.*)
    15 
    16 * MW: check uses of Unsynchronized.ref vs. Synchronized.var;
    17 
    18 * MW: clarify/eliminate Isabelle/Scala add-ons (presently unused)
    19 
    20     diff -r /home/makarius/isabelle/repos-Isabelle2021/src/Pure/build-jars ./src/Pure/build-jars
    21     11a12
    22     >   src/Tools/isac/BridgeJEdit/isac.scala
    23 
    24     diff -r /home/makarius/isabelle/repos-Isabelle2021/src/Pure/Tools/scala_project.scala ./src/Pure/Tools/scala_project.scala
    25     76a77
    26     >       "src/Tools/isac/etc" -> Path.explode("isabelle.isac"),
    27 
    28 * Eliminate Thy_Info.get_theory eventually: should take theory from ancestory
    29   within current context.
    30     cf. e587c45cae0f note in Build_Thydata.thy
    31 
    32 * Clarify symmetric rule: Thm.apply_attribute Calculation.symmetric thm context (!?);
    33     ??
    34 
    35 * KEStore_Elems: Should we eliminate union_overwrite and use standard namespace merge?
    36   (Exception: rlss with its special cross-theory merge.)
    37     ? how adapt the different signatures ?
    38     union_overwrite: ('a * 'a -> bool) -> 'a list -> 'a list -> 'a list
    39     merge          : ('a * 'a -> bool) -> 'a list * 'a list -> 'a list
    40 
    41 * What is the purpose of "#numeral" instead of plain numeral?
    42     ??
    43 
    44 * Check/clarify Context.theory_name vs. Context.theory_long_name.
    45     present ISAC assumes 2 sessions in the MathEngine, Specify and Interpret, 
    46     and all Isac_Knowledge is in session Isac.
    47     So Context.theory_name suffices
    48 
    49 * Eliminate mutable Rewrite_Ord.rew_ord' (!?);
    50     shall be done in connection with cf. e587c45cae0f note in Build_Thydata.thy
    51 
    52 * What is the idea behind KEStore_Elems.add_thes? How to do it properly in current Isabelle?
    53     https://static.miraheze.org/isacwiki/0/04/Isac-docu.pdf distinguishes 
    54     several kinds of ISAC users, in particular "math author (Mathematik-Autor)" and
    55     "course designer (Kurs-Designer)". The latter just adds examples which re-use existing
    56     knowledge designed by the former. KEStore_Elems.add_thes is an interface for the latter.   
    57 
    58 * WN: proper ML antiquotations for "Tactical.Try" etc. --- be careful about unclear situations,
    59   e.g. "Tactical.Try" vs. "Lucas_Interpreter.Try";
    60 
    61 * WN: Avoid Thm.get_name_hint and use Global_Theory.get_thm instead, get theory from References.T
    62     and push theory through as argument of respective functions.
    63 
    64 * WN: more direct logical foundations wrt. Isabelle/HOL, eliminate many axiomatizations
    65     - quite often "axiomatization ..." can be turned into "lemma ... by auto"
    66       without further ado;
    67     - sometimes this requires to use more specific types / type classes;
    68     - sometimes this requires to use proper definitional mechanisms (e.g. 'primrec', 'fun');
    69     - a few "hard" cases will remain, to be reconsidered eventually (e.g. differentiation);
    70 
    71 * WN: "fun pr_ord" is not required if used with @{make_string}, @{print}, @{print tracing};
    72     takes only static arguments ----------------^^^^^^^^^^^^^^, not value of "hd_ord (f, g)"
    73     ? are there better approximations to old output of (*1*) than with (*2*)
    74     (*1*)val _ = tracing ("hd_ord (f, g)      = " ^ ((pr_ord o hd_ord) (f, g)) );
    75     (*2*)val _ = @{print tracing}{a = "hd_ord (f, g)      = ", z = hd_ord (f, g)}(**)
    76 
    77 
    78 * WN: eliminate global flags like "trace_on", replace Unsynchronized.ref by
    79 
    80 ML \<open>
    81   val rewrite_trace = Attrib.setup_config_bool \<^binding>\<open>rewrite_trace\<close> (K false);
    82 \<close>
    83 
    84 * WN: redesign transition from Specification to Solution: how relate 
    85     - Formalise.model with variants (e.g. VSCode_Example)
    86       reconsider separation of variants F_I, F_II, see MAWEN paper
    87     - !?! I_Model of MethodC          (fairly free sequence, dependent on Formalise.model)
    88     - !?! formal arguments of program (fixed sequence)
    89