Dear Mikhail,

I've been successfully using your patch on Isabelle2020. Though I tried hard, I couldn't make it work for the current development version (I only managed to make it work with non-nested scripts). Would you mind giving me some hints on how to adapt it?

I'm about to present a formalization to other mathematicians and a smooth notation is key.

Thank you very much in advance,

--
Pedro Sánchez Terraf
CIEM-FAMAF — Universidad Nacional de Córdoba
cs.famaf.unc.edu.ar/~pedro

On 18/8/20 19:51, Mikhail Mandrykin wrote:
Hello,

Concerning applying the patch, I’m not familiar with hg but in git I’d
try checking out the commit mentioned in the path, apply it there and
hope for merge to do it’s magic.
Just in case I adapted the patch for Isabelle 2020 (last relevant commit 97ccf48c2f0c) and it works for me on some non-trivial theories with nested subscripts and superscripts (I also don't have any previous experience with Isabelle/Scala though)

Sample original theory source fragment:
⬚‹
also from Sucinner have
"... = - G κ⇘i+1⇙ κ⇘i+2⇙
+ int (∑x|x<m⇘κ⇘i+1⇙⇙∧x⇧♮∈vars K⇘κ⇘i+1⇙⇙.
MAX⇩0 t∈terms K⇘κ⇘i+1⇙⇙|t~P⇘κ⇘i+2⇙⇙!0. #⇘x⇧♮⇙ t * size (σ⇘i+1⇙ x⇧♮))
- int (∑x≤(m⇘κ⇘i+1⇙⇙ - 1)⇧♯. #⇩x (P⇘κ⇘i+1⇙⇙!0) * size (σ⇘i+1⇙ x))"
(is "_ + int (∑x∈?S. ?g x) - _ = _ + int (∑x∈?T. ?h x)- _") by

Regards,
Mikhail

Benedikt Nordhoff писал 2020-08-13 14:33:
Dear Pedro,

I’m certainly not the most qualified to answer this. I haven’t build
Isabelle from source for quite a while. I think back then I used the

Best Benedikt

Am 12.08.2020 um 17:36 schrieb Pedro Sánchez Terraf <sterraf at famaf.unc.edu.ar>:

Dear Benedikt,

Sorry to bother you with an dumb question, but I do not know how to build jEdit. Could you point me to some docs where I can find this? (Note: I'm not a computer scientist but I can manage some stuff).
It seems that there have been many some movements and the patch should be applied somewhere in

Tools/jEdit/src/syntax_style.scala,
but I could be wrong.

Best wishes,
PST.-
cs.famaf.unc.edu.ar/~pedro/home_en <https://cs.famaf.unc.edu.ar/~pedro/home_en.html>

El 10/8/20 a las 04:27, Benedikt Nordhoff escribió:
Dear Pedro,

I implemented basic support for this for Isabelle 2014 but it never made it into any release. It worked fine till the 2017 release, I haven’t tried the patch on later versions. If you’re interested and want to try whether the patch still works you can find it here: https://lists.cam.ac.uk/mailman/htdig/cl-isabelle-users/2014-August/msg00214.html <https://lists.cam.ac.uk/mailman/htdig/cl-isabelle-users/2014-August/msg00214.html>

Best
Benedikt

Am 28.07.2020 um 15:45 schrieb Pedro Sánchez Terraf <sterraf at famaf.unc.edu.ar> <mailto:sterraf at famaf.unc.edu.ar>:

Good day,

I have a question concerning the use of superscripts as arguments to functions. I have a function ccc_rel that has 3 arguments, and I would like that the syntax for the first one is a superscript. (I'm working in ZF, don't know if that is relevant.)

If I enter

notation ccc_rel (‹ccc⇧_'(_,_')›)

everything works fine *until* the first argument has more than one character. If I use \<bsup>...\<esup> instead:

notation ccc_rel (‹ccc⇗_⇖'(_,_')›)

it accepts a multi-character first argument but it the PIDE does not prettyprints the superscript.

Can I have the cake and eat it?

PST.-
cs.famaf.unc.edu.ar/~pedro/home_en <https://cs.famaf.unc.edu.ar/~pedro/home_en.html> <https://cs.famaf.unc.edu.ar/~pedro/home_en.html>

As usual, sorry, if this is a double up, but I did search through th= e list for related posts without success.

I have been a bit frustrated recently by phantom lo= cale notations making my proof states impossible to read.

It seems to come up in locale hiera= rchies where the notation for abbreviations is changed to reflect streng= thened defining properties.

This is a simple example:

locale pos =3D=C2=A0<= /span>
fixes
=C2=A0=C2=A0x :: int
assumes
=C2=A0=C2=A0x_pos: =E2=80=B90 =E2=89=A4 x=E2=80=BA
begin

abbreviation
=E2=80=B9half =E2= =89=A1 x div 2=E2=80=BA
notation
half ("=E2=99=A3")

end
<= br style=3D"font-family:Helvetica;" />locale big =3D pos +=C2=A0
assumes
=C2=A0= =C2=A0x_big: =E2=80=B910 =E2=89=A4 x=E2=80=BA

begin

notation
half ("=E2=99=A0")

end

locale pos_big =3D=C2=A0
big +
Y:= pos y
for
=C2=A0=C2=A0y

begin

term "half" =E2=80=95=E2=80=B9result: "=E2=99=A3"=E2=80=BA= =C2=A0

end
It seems that the locale expre= ssion is including the pos notation for half (rather than Y.half) and it= is overriding the big notation for half!

If I reverse the order of inclusion this changes.

locale big_pos =3D=C2=A0
Y: pos y +<= br style=3D"font-family:Helvetica;" />big
for
=C2=A0=C2=A0y

begin

term "half" =E2=80=95=E2=80=B9result: "=E2=99=A0"=E2=80= =BA=C2=A0

end<= br style=3D"font-family:Helvetica;" />
This is often a viable a wor= k around, but not always. For example if I have a local interpretation i= n the locale the same phenomena occurs.

I am tempted to see this as a bug, rather than a feat= ure.

```                          Open Call for Papers
**************************************************************************
Proceedings for ThEdu'21
Theorem Proving Components for Educational Software
http://www.uc.pt/en/congressos/thedu/thedu21
**************************************************************************
Electronic Proceedings in Theoretical Computer Science
http://published.eptcs.org
**************************************************************************

Synopsis

ThEdu'21, was accepted as a workshop at CADE28 The 28th
International Conference on Automated Deduction, 11-16 July 2021.
Because of the COVID-19 pandemic, CADE28 and all its workshops were
virtual events. It was a very lively virtual meeting with an average
of 18 attendees. ThEdu'21 programme comprised one invited talk, 11
regular contributions and one demonstration, whose abstracts,
presentations and videos are in the workshop web-page.

Now post-proceedings are planned to collect the contributions
upgraded to full papers. The contributions' topics are diverse
according to ThEdu's scope, and this is a call open for everyone,
also those who did not participate in the workshop. All papers will
undergo review according to EPTCS standards.

ThEdu'21 Scope:

Computer Theorem Proving is becoming a paradigm as well as a
technological base for a new generation of educational software in
science, technology, engineering and mathematics. This volume of
EPTCS intends to bring together experts in automated deduction with
experts in education in order to further clarify the shape of the
new software generation and to discuss existing systems.

Important Dates

* Submission (Full Papers): 10 October 2021
* Notification of acceptance: 28 November 2021
* Revised papers due: 12 December 2021

Topics of interest include:

* methods of automated deduction applied to checking students' input;
* methods of automated deduction applied to prove post-conditions
for particular problem solutions;
* combinations of deduction and computation enabling systems to
propose next steps;
* automated provers specific for dynamic geometry systems;
* proof and proving in mathematics education.

Submission

We welcome submission of full papers (12--20 pages) presenting
original unpublished work which is not being submitted for
publication elsewhere.

All contributions will be reviewed (at least three blind reviews) to
meet the high standards of EPTCS.

The authors should comply with the "instructions for authors", LaTeX
style files and accept the "Non-exclusive license to distribute" of
EPTCS: Instructions for authors (http://info.eptcs.org/) LaTeX style
file and formatting instructions (http://style.eptcs.org/) Copyright

Papers should be submitted via EasyChair,
https://easychair.org/conferences/?conf=thedu21.

Program Committee

Francisco Botana, University of Vigo at Pontevedra, Spain
David Cerna, Johannes Kepler University, Austria
João Marcos, Universidade Federal do Rio Grande do Norte, Brazil (co-chair)
Filip Maric, University of Belgrade, Serbia
Walther Neuper, Graz University of Technology, Austria (co-chair)
Pedro Quaresma, University of Coimbra, Portugal (co-chair)
Philippe R. Richard, Université de Montréal, Canada
Vanda Santos, University of Aveiro, Portugal
Wolfgang Schreiner, Johannes Kepler University, Austria
Jørgen Villadsen, Technical University of Denmark, Denmark
```
Hello,

I'm currently exploring seve= ral graph representations and encountered an unexpected=C2=A0exception usin= g the lifting package. The following code:
```
type_synonym 'i graph_rep =3D "'i fset =C3=97 'i fset =C3= =97 ('i,'i) fmap =C3=97 ('i,'i) fmap"

typedef &= #39;i graph =3D
=C2=A0 "{(nodes, edges, src, trg) :: 'i graph_= rep |
=C2=A0 =C2=A0 =C2=A0 nodes edges src trg.
=C2=A0 fmdom src |= =E2=8A=86| edges =E2=88=A7 fmran src |=E2=8A=86| nodes =E2=88=A7 fmdom trg = |=E2=8A=86| edges =E2=88=A7 fmran trg |=E2=8A=86| nodes
=C2=A0 }"=C2=A0 apply (rule exI[where x =3D "(fempty, fempty, fmempty, fmempt= y)"])
=C2=A0 by simp

setup_lifting type_definition_graph
=
```

produces the exception:
=
```
exception THM 1 raised (line 1828 of "thm.ML&q= uot;):
=C2=A0 dest_state
=C2=A0 Quotient (fmrel R) (fmmap Abs) (fmm= ap Rep) (fmrel T) =C2=A0[Quotient R Abs Rep T]
```

=
Would be great to receive some comments and potential suggestions on h= ow to overcome this=C2=A0issue.

Robert

When using = Interpretation.interpretation within Isabelle/ML the declarations of the = interpreted locale are surprisingly not activated.

I = attempt to accumulate some facts in named theorems that come from the = interpretation.

In Isar it reads and works perfectly = fine as follows:

named_theorems
my_rules

locale nonzero =3D
fixes n::nat
assumes non_zero: "0 < = n"
begin
lemma le [my_rules]: "Suc 0 < = Suc n"
thm = my_rules =E2=80=95=E2=80=B9Suc 0 < Suc n=E2=80=BA
end

thm my_rules =E2=80=95=E2=80=B9empty=E2=80= =BA

locale foo =3D
fixes m::nat
assumes m[simp]: "m =3D Suc (Suc 0)"
begin

thm my_rules =E2=80=95=E2=80=B9empty=E2=80= =BA

interpretation two: nonzero where n=3Dm
by (unfold_locales) simp
thm two.le
thm = my_rules =E2=80=95=E2=80=B9@{term =E2=80=B9Suc 0 < Suc = m=E2=80=BA}=E2=80=BA

interpretation one: nonzero where = n=3D"Suc 0"
by (unfold_locales) simp

thm = my_rules =E2=80=95=E2=80=B9@{term =E2=80=B9Suc 0 < Suc m=E2=80=BA}, = @{term =E2=80=B9Suc 0 < Suc (Suc 0)=E2=80=BA}=E2=80=BA
thm = one.le
thm two.le

end

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I expected the same to = happen in Isabelle/ML using Interpretation.interpretation.
However there is no effect on my_rules

ML = =E2=80=B9
val expr_one =3D ([(@{locale "nonzero"}, (("one", = true),
(Ex= pression.Positional ([SOME @{term "Suc 0"}]), [])))], [])
=E2=80=BA

context foo
begin
ML_val =E2=80=B9
val = lthy =3D
@{context}
|> Interpretation.interpretation expr_one =
|> Proof.global_terminal_proof ((Method.Basic = (fn ctxt =3D>  SIMPLE_METHOD (
(Locale.intro_locales_tac = {strict =3D false, eager =3D true} ctxt [] THEN
asm_full_simp_tac = ctxt 1))), Position.no_range), NONE)

val = thms =3D Named_Theorems.get lthy @{named_theorems my_rules} = =E2=80=95=E2=80=B9[]=E2=80=BA

=E2=80=BA
end

ML_val =E2=80=B9
val = lthy =3D
@{theory}
|> Named_Target.init [] @{locale foo}
|> Interpretation.interpretation expr_one =             &n= bsp;
|> Proof.global_terminal_proof = ((Method.Basic (fn ctxt =3D>  SIMPLE_METHOD (
(Locale.intro_locales_tac = {strict =3D false, eager =3D true} ctxt [] THEN
asm_full_simp_tac = ctxt 1))), Position.no_range), NONE)

val = thms =3D Named_Theorems.get lthy @{named_theorems my_rules}
=E2=80=BA

Any suggestions on how to approach = this in Isabelle/ML?

Find the source and some more = examples in the attachment.

Regards,
Norbert

--

Norbert Schirmer = (nschirmer at apple.com)
=EF=A3=BF SEG Formal = Verification
Regards,
Norbert

--

Norbert = Schirmer (nschirmer at apple.com)
=EF=A3=BF SEG Formal = Verification

= --Apple-Mail=_4177C91E-1338-449E-8F2C-29555140FB6A Content-Disposition: attachment; filename=Interpretation_Ex.thy Content-Type: application/octet-stream; x-unix-mode=0644; name="Interpretation_Ex.thy" Content-Transfer-Encoding: 7bit theory Interpretation_Ex imports "Main" begin named_theorems my_rules locale nonzero = fixes n::nat assumes non_zero: "0 < n" begin lemma le [my_rules]: "Suc 0 < Suc n" by (simp add: non_zero) thm my_rules \\Suc 0 < Suc n\ end thm my_rules \\empty\ locale foo = fixes m::nat assumes m[simp]: "m = Suc (Suc 0)" begin thm my_rules \\empty\ interpretation two: nonzero where n=m by (unfold_locales) simp thm two.le thm my_rules \\@{term \Suc 0 < Suc m\}\ interpretation one: nonzero where n="Suc 0" by (unfold_locales) simp thm my_rules \\@{term \Suc 0 < Suc m\}, @{term \Suc 0 < Suc (Suc 0)\}\ thm one.le thm two.le end context foo begin thm my_rules end thm my_rules \\empty\ text \I expected the same to happen in Isabelle/ML using @{ML Interpretation.interpretation}. However there is no effect on @{thm my_rules}.\ ML \ val expr_one = ([(@{locale "nonzero"}, (("one", true), (Expression.Positional ([SOME @{term "Suc 0"}]), [])))], []) \ context foo begin ML_val \ val lthy = @{context} |> Interpretation.interpretation expr_one |> Proof.global_terminal_proof ((Method.Basic (fn ctxt => SIMPLE_METHOD ( (Locale.intro_locales_tac {strict = false, eager = true} ctxt [] THEN asm_full_simp_tac ctxt 1))), Position.no_range), NONE) val thms = Named_Theorems.get lthy @{named_theorems my_rules} \\[]\ \ end ML_val \ val lthy = @{theory} |> Named_Target.init [] @{locale foo} |> Interpretation.interpretation expr_one |> Proof.global_terminal_proof ((Method.Basic (fn ctxt => SIMPLE_METHOD ( (Locale.intro_locales_tac {strict = false, eager = true} ctxt [] THEN asm_full_simp_tac ctxt 1))), Position.no_range), NONE) val thms = Named_Theorems.get lthy @{named_theorems my_rules} \ text \The same non-effect happens in the theory target.\ ML_val \ val lthy = @{theory} |> Named_Target.theory_init |> Interpretation.interpretation expr_one |> Proof.global_terminal_proof ((Method.Basic (fn ctxt => SIMPLE_METHOD ( (Locale.intro_locales_tac {strict = false, eager = true} ctxt [] THEN asm_full_simp_tac ctxt 1))), Position.no_range), NONE) val thms = Named_Theorems.get lthy @{named_theorems my_rules} val lthy' = lthy |> Local_Theory.exit_global |> Named_Target.theory_init val thms' = Named_Theorems.get lthy' @{named_theorems my_rules} \ text \Using @{ML Interpretation.global_interpretation} only shows its effect after exiting and reentering the theory target.\ ML_val \ val lthy = @{theory} |> Named_Target.theory_init |> Interpretation.global_interpretation expr_one [] |> Proof.global_terminal_proof ((Method.Basic (fn ctxt => SIMPLE_METHOD ( (Locale.intro_locales_tac {strict = false, eager = true} ctxt [] THEN asm_full_simp_tac ctxt 1))), Position.no_range), NONE) val thms = Named_Theorems.get lthy @{named_theorems my_rules} \\[]\ val lthy' = lthy |> Local_Theory.exit_global |> Named_Target.theory_init val thms' = Named_Theorems.get lthy' @{named_theorems my_rules} \\["Suc 0 < Suc (Suc 0)"]\ \ text \The same can be observed in a locale when using @{ML Interpretation.sublocale}.\ context foo begin ML_val \ val lthy = @{context} |> Interpretation.sublocale expr_one [] |> Proof.global_terminal_proof ((Method.Basic (fn ctxt => SIMPLE_METHOD ( (Locale.intro_locales_tac {strict = false, eager = true} ctxt [] THEN asm_full_simp_tac ctxt 1))), Position.no_range), NONE) val thms = Named_Theorems.get lthy @{named_theorems my_rules} \\[]\ val lthy' = lthy |> Local_Theory.exit_global |> Named_Target.init [] @{locale foo} val thms' = Named_Theorems.get lthy' @{named_theorems my_rules} \\[]\ \ end thm my_rules \\empty\ interpretation one: nonzero where n="Suc 0" by (unfold_locales) simp thm my_rules \\Suc 0 < Suc (Suc 0)\ end --Apple-Mail=_4177C91E-1338-449E-8F2C-29555140FB6A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Unfortunately= this also does not show any effect.

Regards,
Norbert

--

Norbert = Schirmer (nschirmer at apple.com)
=EF=A3=BF SEG Formal = Verification

On 20. Sep 2021, at 20:19, Clemens Ballarin <ballarin at in.tum.de> = wrote:

Hi Norbert,

There have been many refactorings since I've implemented = this, so I cannot tell you for sure. However, it seems to me that you = should be using 'isar_interpretation' rather than = 'interpretation'.

Clemens

On 2021-09-17 15:29, Norbert Schirmer via Cl-isabelle-users = wrote:
Hi,
When using Interpretation.interpretation within Isabelle/ML = the
declarations of the interpreted locale are = surprisingly not activated.
I attempt to accumulate some = facts in named theorems that come from
the = interpretation.
In Isar it reads and works perfectly fine = as follows:
named_theorems
my_rules
locale nonzero =3D
fixes n::nat
assumes non_zero: "0 < n"
begin
lemma le [my_rules]: "Suc 0 < Suc n"
thm my_rules =E2=80=95=E2=80=B9Suc 0 = < Suc n=E2=80=BA
end
thm my_rules = =E2=80=95=E2=80=B9empty=E2=80=BA
locale foo =3D
fixes m::nat
assumes m[simp]: "m =3D Suc (Suc = 0)"
begin
thm my_rules =E2=80=95=E2=80=B9empty= =E2=80=BA
interpretation two: nonzero where n=3Dm
by (unfold_locales) simp
thm two.le
thm my_rules =E2=80=95=E2=80=B9@{term =E2=80=B9Suc 0 < Suc = m=E2=80=BA}=E2=80=BA
interpretation one: nonzero where = n=3D"Suc 0"
by (unfold_locales) simp
thm = my_rules =E2=80=95=E2=80=B9@{term =E2=80=B9Suc 0 < Suc m=E2=80=BA}, = @{term =E2=80=B9Suc 0 < Suc (Suc 0)=E2=80=BA}=E2=80=BA
thm one.le
thm two.le
end
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I expected the same = to happen in Isabelle/ML using
Interpretation.interpretation.
However there is = no effect on my_rules
ML =E2=80=B9
val = expr_one =3D ([(@{locale "nonzero"}, (("one", true),
(Expressi= on.Positional ([SOME @{term "Suc 0"}]), [])))], [])
=E2=80=BA=
context foo
begin
ML_val = =E2=80=B9
val lthy =3D
@{context}
|> Interpretation.interpretation expr_one
|> Proof.global_terminal_proof ((Method.Basic (fn ctxt = =3D>  SIMPLE_METHOD (
(Locale.intro_locales_tac = {strict =3D false, eager =3D true} ctxt [] THEN
asm_full_simp_tac ctxt = 1))), Position.no
<http://position.no/>_range), NONE)
val = thms =3D Named_Theorems.get lthy @{named_theorems my_rules} = =E2=80=95=E2=80=B9[]=E2=80=BA
=E2=80=BA
endML_val =E2=80=B9
val lthy =3D
@{theory}
|> Named_Target.init [] @{locale = foo}
|> Interpretation.interpretation expr_one
|> Proof.global_terminal_proof ((Method.Basic (fn ctxt = =3D>  SIMPLE_METHOD (
(Locale.intro_locales_tac = {strict =3D false, eager =3D true} ctxt [] THEN
asm_full_simp_tac ctxt = 1))), Position.no
<http://position.no/>_range), NONE)
val = thms =3D Named_Theorems.get lthy @{named_theorems my_rules}
=E2=80=BA
Any suggestions on how to approach = this in Isabelle/ML?
Find the source and some more = examples in the attachment.
Regards,
Norbert
--
Norbert Schirmer (nschirmer at apple.com <mailto:nschirmer at apple.com>)
=EF=A3=BF = SEG Formal Verification
Regards,
Norbert
--
Norbert Schirmer (nschirmer at apple.com)=EF=A3=BF SEG Formal = Verification

On 22. Sep 2021, at 13:03, Makarius <makarius at sketis.net>= wrote:

2. Whether position information is = displayed or not seems to depend on how the
structure is = actually generated, ie.
via. Theory_Data=E2=80=99, = Theory_Data, or Generic_Data and also how the arguments are
declared. Some observations:
* Theory_Data=E2=80=99= seems to result in a filename as position
* = Generic_Data(struct Type T =3D =E2=80=A6 end) seems to result in a link = as position
* Generic_Data(Type T =3D =E2=80=A6) (without = the explicit struct) seems to have no
position = information.

I could not reproduce this observation.

Below is some example = output from my debug-version (based on Isabelle2021) were I have = explicitly named the data slots (cf. "name" below). Note the difference = in the output for
sign.ML, locale.ML = (locale), classical.ML. My guess was that it might be related to how the = data slot is declared. Or is it related to the build (bootstrap) process = of the sessions?

=46rom = context.ML:

type kind =3D
{pos: = Position.T,
name: string,
empty: Any.T,
extend: = Any.T -> Any.T,
merge: theory * theory = -> Any.T * Any.T -> Any.T};

fun invoke name f k x =3D
(case Datatab.lookup (Synchronized.value kinds) k = of
SOME kind =3D>
if ! timing andalso name <> "" = then
Timing.cond_timeit = true ("Theory_Data." ^ name ^ Position.here (#pos kind) ^ " " ^ (#name = kind))
(fn () = =3D> f kind x)
else f kind = x
| NONE =3D> raise Fail "Invalid theory = data identifier");

=46rom sign.ML:

structure Data =3D = Theory_Data'
(
type T =3D= sign;
val name =3D "sign.ML";
val extend =3D I;
val = empty =3D make_sign (Syntax.empty_syntax, Type.empty_tsig, = Consts.empty);
fun merge old_thys (sign1, = sign2) =3D
let
val Sign {syn =3D syn1, tsig =3D tsig1, = consts =3D consts1} =3D sign1;
= val Sign {syn =3D syn2, tsig =3D tsig2, consts =3D consts2} =3D = sign2;

=     val syn =3D Syntax.merge_syntax (syn1, syn2);
val tsig =3D Type.merge_tsig = (Context.Theory (fst old_thys)) (tsig1, tsig2);
val consts =3D Consts.merge (consts1, = consts2);
in make_sign (syn, tsig, = consts) end;
);

=46rom locale.ML:

structure = Locales =3D Theory_Data
(
= type T =3D locale Name_Space.table;
val = name =3D "locale.ML (locale)";
val empty : T = =3D Name_Space.empty_table "locale";
val = extend =3D I;
val merge =3D = Name_Space.join_tables (K merge_locale);
);

=46rom classical.ML:

structure Claset =3D = Generic_Data
(
type T =3D= claset;
val name =3D = "classical.ML";
val empty =3D = empty_cs;
val extend =3D I;
val merge =3D merge_cs;
);

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Theory_Data.merge (file "sign.ML") = sign.ML
0.223s elapsed time, 1.291s cpu time, = 0.707s GC time
Theory_Data.merge (file = "theory.ML") theory.ML
0.017s elapsed time, 0.105s = cpu time, 0.000s GC time
Theory_Data.merge = (file "thm.ML") thm.ML
0.003s elapsed time, 0.020s = cpu time, 0.000s GC time
Theory_Data.merge = (file "global_theory.ML") global_theory.ML
0.073s = elapsed time, 0.432s cpu time, 0.000s GC time
Theory_Data.merge (file "raw_simplifier.ML") = raw_simplifier.ML (simpset)
0.005s elapsed time, = 0.032s cpu time, 0.000s GC time
Theory_Data.merge (file "ML/ml_env.ML") ml_env.ML
0.000s elapsed time, 0.001s cpu time, 0.000s GC = time
Theory_Data.merge attrib.ML = (attribute)
0.000s elapsed time, 0.001s cpu time, = 0.000s GC time
Theory_Data.merge = context_rules.ML
0.006s elapsed time, 0.047s cpu = time, 0.000s GC time
Theory_Data.merge = locale.ML (locale)
0.000s elapsed time, 0.001s cpu = time, 0.000s GC time
Theory_Data.merge = locale.ML (idents)
0.017s elapsed time, 0.089s cpu = time, 0.000s GC time
Theory_Data.merge = locale.ML (global_registrations)
0.000s elapsed = time, 0.006s cpu time, 0.000s GC time
Theory_Data.merge locale.ML (thms)
0.001s = elapsed time, 0.004s cpu time, 0.000s GC time
Theory_Data.merge bundle.ML
0.000s = elapsed time, 0.002s cpu time, 0.000s GC time
Theory_Data.merge axclass.ML
0.000s = elapsed time, 0.005s cpu time, 0.000s GC time
Theory_Data.merge class.ML
0.000s = elapsed time, 0.002s cpu time, 0.000s GC time
Theory_Data.merge code.ML
0.001s elapsed = time, 0.014s cpu time, 0.000s GC time
Theory_Data.merge spec_rules.ML
0.002s = elapsed time, 0.010s cpu time, 0.000s GC time
Theory_Data.merge named_theorems.ML
0.003s= elapsed time, 0.011s cpu time, 0.000s GC time
Theory_Data.merge generated_files.ML
0.000s elapsed time, 0.001s cpu time, 0.000s GC = time
Theory_Data.merge (line 788 of = "~~/src/HOL/HOL.thy") classical.ML
0.002s elapsed = time, 0.009s cpu time, 0.000s GC time
Theory_Data.merge (line 1529 of "~~/src/HOL/HOL.thy") = induct.ML
0.001s elapsed time, 0.006s cpu time, = 0.000s GC time
Theory_Data.merge (line 416 of = "~~/src/HOL/Inductive.thy") inductive.ML
0.000s = elapsed time, 0.001s cpu time, 0.000s GC time
Theory_Data.merge (line 13 of "~~/src/HOL/Fun_Def_Base.thy") = function_common.ML
0.000s elapsed time, 0.006s cpu = time, 0.000s GC time
Theory_Data.merge (line = 14 of "~~/src/HOL/Fun_Def_Base.thy") function_context_tree.ML
0.000s elapsed time, 0.004s cpu time, 0.000s GC = time
Theory_Data.merge (line 260 of = "~~/src/HOL/Transfer.thy") transfer.ML
0.001s = elapsed time, 0.007s cpu time, 0.000s GC time

Regards,
Norbert

--

Norbert Schirmer (nschirmer at apple.com)
=EF=A3=BF SEG Formal = Verification

On 22. Sep 2021, at 13:34, Makarius <makarius at sketis.net>= wrote:

Maybe you can rephrase most of = this directly with the 'def' command from
https://isabelle-dev.sketis.net/source/isabelle/browse/default/= src/Pure/ex/Def.thy;f79dfc7656ae
(it should also work with current Isabelle2021).

Thanks a lot for the explanations and examples and work = into the direction to improve performance in the mid-term.

I guess with some = combination of hand-crafted declarations (instead of attributes) and = implementing the =E2=80=98def=E2=80=99 idea above I can improve the = performance for our applications.
The tradeoff is = between simplicity / readability vs. performance. Especially the neat = thing about attributes (compared to declarations) is that you can = already provide them to almost all relevant functions like definitions, = derived specifications (like function package) and =E2=80=99notes=E2=80=99= . Note that we not only use plain definitions with large terms but also = derived concepts like (partial) functions which besides the defining = equation also result in a bunch of theorems (like induction) with large = terms.

My main = working-horse is actually the =E2=80=99named_theorems=E2=80=99 attribute = which is only relevant in the body of the locale when doing proofs and = not in the declaration of new locales. So I would reimplement this = functionality with a declaration instead of the existing attribute, = explicitly postponing the application of the morphism. Thats why I = mentioned the idea of =E2=80=9Clazy attributes=E2=80=9D to implement an = attribute like =E2=80=9Clazy_named_theorems=E2=80=9D that can be = provided to all the already existing functions in Isabelle/ML.

Regards,
Norbert

--

Norbert = Schirmer (nschirmer at apple.com)
=EF=A3=BF SEG Formal = Verification