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