* MW: clarify/eliminate Isabelle/Scala add-ons (presently unused)

    diff -r /home/makarius/isabelle/repos-Isabelle2021/src/Pure/build-jars ./src/Pure/build-jars

    11a12

    >   src/Tools/isac/BridgeJEdit/isac.scala

    diff -r /home/makarius/isabelle/repos-Isabelle2021/src/Pure/Tools/scala_project.scala ./src/Pure/Tools/scala_project.scala

    76a77

    >       "src/Tools/isac/etc" -> Path.explode("isabelle.isac"),

* MW: Skip_Proof.make_thm: theory -> term -> thm        ? could now change signature to

                         : Proof.context -> term -> thm

* How does declare [[LI_trace = true]] and declare [[rewrite_trace = true]] work in ISABELLE_ISAC_TEST ?

***** some items for discussion

* Clarify symmetric rule: Thm.apply_attribute Calculation.symmetric thm context (!?);

    ??

* "fun pr_ord" is not required if used with @{make_string}, @{print}, @{print tracing};

    takes only static arguments ----------------^^^^^^^^^^^^^^, not value of "hd_ord (f, g)"

    ? are there better approximations to old output of (*1*) than with (*2*)

    (*1*)val _ = tracing ("hd_ord (f, g)      = " ^ ((pr_ord o hd_ord) (f, g)) );

    (*2*)val _ = @{print tracing}{a = "hd_ord (f, g)      = ", z = hd_ord (f, g)}(**)

***** for the few items below WN asks MW for help

* MW: make Outer_Syntax.command..‹problem› a model for ..\<open>Example\<close>

  The model should demonstrate, how an ML syntax error is indicated in place 

  (in the string after \<^keyword>\<open>Given\<close> etc) and not on the definition as a whole. 

    - in MathEngBasic/problem "Outer_Syntax.command \<^command_keyword>\<open>problem\<close>" there are writeln

      and comments with testdata from "problem pbl_bieg : "Biegelinien"" in Biegelinie.thy

    - in MathEngBasic/problem there is guesswork ("TODO") how to reorganise "fun prep_input_PIDE"

      such that errors in "Given" etc are indicated WITHIN the term.

* MW: In Outer_Syntax.command..‹Example› help: is there a quick fix

  for successfully replacing hacked Problem.parse_cas by parse_references_input?

    (a) In addition to replacing Problem.parse_cas: How implement the optional parser:

      - Example "Diff_App/No.123 a" + NONE

      - Example "Diff_App/No.123 a" + SOME (probl_id, model_input, refs_input)

        i.e. we expect ISAC to present an empty template "Problem..Solution", but as a whole, to the user;

        see VSCode_Example.thy subsubsection \<open>Specification step by step\<close>

    How get Token.src for testing purposes?

    How can Scan.* be traced?

    (Tracing should help understanding Problem.parse_cas, Problem.parse_model_input which involve Scan.* )

* ?How represent items, which have not yet been input?

   Note: For the purpose of user-guidance the format of requested input should be indicated!

    - proposal for how to indicate requested input: in VSCode_Example.thy subsubsection \<open>Empty Specification>

    - the trial with <fun is_empty> in Calculation.thy makes the question more precise: 

      better hack parsers or better work on ML_Syntax?

* ?How accomplish two user-requirements by Outer_Syntax.command \<^command_keyword>\<open>Example\<close>

   (1) start a Calculation with a CAS_Cmd

   (2) start an Example from scratch, i.e. with (Formalize.empty, References.empty)

   Proposals for a solution are in test/../Test_VSCode_Example.thy

   subsubsection ‹Start Example with a CAS_Cmd›

***** priority of WN items is top down, most urgent/simple on top

* WN: follow up 5: cleanup

      follow up 6: ctxt_user at init Example mimiced by CalcTreeTest @{context}

                   Thus eliminate use of Thy_Info.get_theory

      follow up 7: ANSWER ?How represent items, which have not yet been input? IN VSCode_Example.thy WITH "__"

* WN: improve naming in refine.sml, m-match.sml

* WN: rename ‹ML_structure KEStore_Elems› to ‹ML_structure Know_Store›

* WN: eliminate KEStore_Elems.get_thes, add_thes 

* What is the idea behind KEStore_Elems.add_thes? How to do it properly in current Isabelle?

  See notes in Build_Thydata.thy.

    https://static.miraheze.org/isacwiki/0/04/Isac-docu.pdf distinguishes 

    several kinds of ISAC users, in particular "math author (Mathematik-Autor)" and

    "course designer (Kurs-Designer)". The latter just adds examples which re-use existing

    knowledge designed by the former. KEStore_Elems.add_thes is an interface for the latter.

  KEStore_Elems.get_thes and KEStore_Elems.add_thes are ONLY required for the Lucas-Interpreter

  retrieving Thm and Rls from string-identifiers (which do NOT indicate the theory of) --

  -- get_thes and add_thes are the main reason for (b)

  So: How can KEStore_Elems.get_thes and KEStore_Elems.add_thes be replaced in current Isabelle?

* WN: Specify/formalise.sml is in BaseDefinitions/ AND Specify/  DELETE ONE VERSION

* WN: Step_Specify.initialise_PIDE: remove hdl in return-value, replace Step_Specify.nxt_specify_init_calc

      ? which uses initialise_PIDE !?

* WN: ? unify "no_met" with "empty_meth_id" from References.empty ?

* WN: proper ML antiquotations for "Tactical.Try" etc. --- be careful about unclear situations,

  e.g. "Tactical.Try" vs. "Lucas_Interpreter.Try";

* WN: ? Rational.Cancel_p; extend use of \<^theory> to \<^theory_context>

* WN: Avoid Thm.get_name_hint and use Global_Theory.get_thm instead, get theory from References.T

    and push theory through as argument of respective functions.

* WN: Eliminate Thy_Info.get_theory eventually: should take theory from ancestory

  within current context.

    cf. e587c45cae0f note in Build_Thydata.thy

* WN: Check/clarify Context.theory_name vs. Context.theory_long_name.

    present ISAC assumes 2 sessions in the MathEngine, Specify and Interpret, 

    and all Isac_Knowledge is in session Isac.

    So Context.theory_name suffices

* WN: more direct logical foundations wrt. Isabelle/HOL, eliminate many axiomatizations

    - quite often "axiomatization ..." can be turned into "lemma ... by auto"

      without further ado;

    - sometimes this requires to use more specific types / type classes;

    - sometimes this requires to use proper definitional mechanisms (e.g. 'primrec', 'fun');

    - a few "hard" cases will remain, to be reconsidered eventually (e.g. differentiation);

* WN: eliminate argument theory from Interpret/*, e.g. (LI_Tool.tac_from_prog + see TODO.thy)

* WN: rename Pos.* -- Pos.ints, Pos.spec, Pos.empty, Pos.ints_empty

* WN: redesign transition from Specification to Solution: how relate 

    - Formalise.model with variants (e.g. VSCode_Example)

      reconsider separation of variants F_I, F_II, see MAWEN paper

    - !?! I_Model of MethodC          (fairly free sequence, dependent on Formalise.model)

    - !?! formal arguments of program (fixed sequence)