TODO.md
author wenzelm
Mon, 21 Jun 2021 21:59:10 +0200
changeset 60315 352f02b89e67
parent 60311 26273adbf565
child 60316 63cecf440235
permissions -rw-r--r--
updated TODO;
wenzelm@60234
     1
* reconsider use of Thy_Info.get_theory: only works with batch-build, not within PIDE session;
walther@60258
     2
  + consider in Build_Thydata:  Thy_Hierarchy.insert_errpatIDs
walther@60258
     3
  + consider in Biegelinie.thy: KEStore_Elems.add_thes, 
wenzelm@60234
     4
wenzelm@60234
     5
* MW: check uses of Unsynchronized.ref vs. Synchronized.var;
wenzelm@60234
     6
wenzelm@60216
     7
* MW: clarify/eliminate Isabelle/Scala add-ons (presently unused)
wenzelm@60216
     8
wenzelm@60216
     9
    diff -r /home/makarius/isabelle/repos-Isabelle2021/src/Pure/build-jars ./src/Pure/build-jars
wenzelm@60216
    10
    11a12
wenzelm@60216
    11
    >   src/Tools/isac/BridgeJEdit/isac.scala
wenzelm@60216
    12
wenzelm@60216
    13
    diff -r /home/makarius/isabelle/repos-Isabelle2021/src/Pure/Tools/scala_project.scala ./src/Pure/Tools/scala_project.scala
wenzelm@60216
    14
    76a77
wenzelm@60216
    15
    >       "src/Tools/isac/etc" -> Path.explode("isabelle.isac"),
wenzelm@60225
    16
wenzelm@60281
    17
wenzelm@60295
    18
* Clarify symmetric rule: Thm.apply_attribute Calculation.symmetric thm context (!?);
wenzelm@60295
    19
wenzelm@60285
    20
* Is it possible to eliminate union_overwrite, in favour of more standard data
wenzelm@60285
    21
  add/merge discipline?
wenzelm@60285
    22
wenzelm@60281
    23
* What is the purpose of "#numeral" instead of plain numeral?
wenzelm@60281
    24
wenzelm@60281
    25
* Check/clarify Context.theory_name vs. Context.theory_long_name.
wenzelm@60281
    26
wenzelm@60292
    27
* Eliminate mutable Rewrite_Ord.rew_ord' (!?);
wenzelm@60292
    28
wenzelm@60315
    29
* What is the idea behind KEStore_Elems.add_thes? How to do it properly in current Isabelle?
wenzelm@60315
    30
wenzelm@60315
    31
wenzelm@60315
    32
* WN: clarify add_calcs with non-existant constant "Integrate.add_new_c";
wenzelm@60229
    33
wenzelm@60311
    34
* WN: proper ML antiquotations for "Tactical.Try" etc. --- be careful about unclear situations,
wenzelm@60311
    35
  e.g. "Tactical.Try" vs. "Lucas_Interpreter.Try";
wenzelm@60311
    36
wenzelm@60304
    37
* WN: eliminate ThmC.numerals_to_Free, use existing Isabelle/HOL representation
wenzelm@60304
    38
    - clarify role of type "real" vs. "float" (see theory "HOL-Library.Float");
wenzelm@60302
    39
wenzelm@60311
    40
* WN: proper formal context with theory HOL-Library.Float, proper antiquotation @{const_name Float};
wenzelm@60311
    41
wenzelm@60301
    42
* WN: clarify Rule.Thm ("minus_divide_left", ...): Should this be @{rule_thm_sym} antiquotation?
wenzelm@60301
    43
wenzelm@60304
    44
* WN: check remaining MethodC.prep_input that use a different theory (e.g. "Diff"):
wenzelm@60304
    45
  Is this really required, or can we just use the 'method' command?
wenzelm@60304
    46
wenzelm@60311
    47
* WN: trim-down MethodC.prep_input and Problem.prep_input to what is really needed;
wenzelm@60311
    48
  improve errors via parse_term_strict;
wenzelm@60287
    49
wenzelm@60304
    50
* WN: eliminate global flags like "trace_on", replace Unsynchronized.ref by
wenzelm@60304
    51
wenzelm@60304
    52
    ML \<open>val rewrite_trace = Attrib.setup_config_bool \<^binding>\<open>rewrite_trace\<close> (K false);\<close>
wenzelm@60304
    53
wenzelm@60304
    54
* WN: Avoid Thm.get_name_hint --- somewhat fragile.
wenzelm@60304
    55
wenzelm@60284
    56
* WN: eliminate ThyC.to_ctxt, use Proof_Context.init_global inline to make more
wenzelm@60284
    57
  clear where the normal Isabelle context-discipline is bypassed;
wenzelm@60284
    58
wenzelm@60241
    59
* WN: more direct logical foundations wrt. Isabelle/HOL, eliminate many axiomatizations
wenzelm@60241
    60
    - quite often "axiomatization ..." can be turned into "lemma ... by auto"
wenzelm@60241
    61
      without further ado;
wenzelm@60241
    62
    - sometimes this requires to use more specific types / type classes;
wenzelm@60241
    63
    - sometimes this requires to use proper definitional mechanisms (e.g. 'primrec', 'fun');
wenzelm@60241
    64
    - a few "hard" cases will remain, to be reconsidered eventually (e.g. differentiation);
wenzelm@60234
    65
wenzelm@60247
    66
* WN: "fun pr_ord" is not required if used with @{make_string}, @{print}, @{print tracing};