From lukas.stevens+isabelle-users at in.tum.de Tue Jul 7 13:09:51 2026 From: lukas.stevens+isabelle-users at in.tum.de (Lukas Stevens) Date: Tue, 7 Jul 2026 13:09:51 +0200 Subject: Printing of dummy terms in syntax translations Message-ID: <66c78c92-a3fd-4e67-ad8e-52abef215f93@in.tum.de> Dear Isabelle developers, I am working on the type annotation algorithm in ~~/src/HOL/Tools/Sledgehammer/sledgehammer_isar_annotate.ML that is used by some interactive tools, e.g., Sledgehammer and Sketch and Explore. The algorithm places type annotations in terms such that printing and then parsing them again yields a term with the same type as the original term. This is crucial when trying to output well-formed Isar proofs. While testing the algorithm, I ran into some unfortunate behavior that results from the interaction of Syntax_Trans.atomic_abs_tr' and the syntax translation case_prod_tr'/case_prod_guess_names_tr' in Product_Type.thy. You can observe this behavior in Isabelle/333ffbe82f5f, where   term "λ_. 1 :: nat" yields "λ_. 1" :: "'a ⇒ nat" while   term "λ(x, _). 1 :: nat" gives "λ(x, uu_). 1" :: "'a × 'b ⇒ nat", which contains an internal variable uu_. The latter term cannot be parsed after printing it due to the internal variable. Note that the same behavior surfaces for other users of Syntax_Trans.atomic_abs_tr' such as the translations for SOME and set comprehensions. The reason for the first term being printed without internal variables is the changeset Isabelle/41986849fee0 that adds support for the syntax constant _idtdummy (printed as _) to Syntax_Trans.abs_tr'/mk_binder_tr'; however, case_prod_tr'/case_prod_guess_names_tr' internally uses Syntax_Trans.atomic_abs_tr', which has no support for _idtdummy. This could be changed by a 4-line modification of Syntax_Trans.atomic_abs_tr' (see attached diff), which produces the right result on the surface, although I am not sure if there is any collateral. Anecdotally, I know that users of Sketch and Explore have stumbled over this behavior. Cheers, Lukas -------------- next part -------------- diff -r 2300745395fc src/Pure/Syntax/syntax_trans.ML --- a/src/Pure/Syntax/syntax_trans.ML Wed Jul 01 12:27:01 2026 +0100 +++ b/src/Pure/Syntax/syntax_trans.ML Tue Jul 07 11:43:26 2026 +0200 @@ -345,8 +345,11 @@ (strip_abss ctxt strip_abs_vars strip_abs_body (eta_contr ctxt tm)); fun atomic_abs_tr' ctxt (x, T, t) = - let val xT = singleton (variant_bounds ctxt t) (x, T) - in (mark_bound_abs xT, subst_bound (mark_bound_body xT, t)) end; + if Name.is_internal x andalso not (Term.is_dependent t) then + (Const ("_idtdummy", T), incr_boundvars ~1 t) + else + let val xT = singleton (variant_bounds ctxt t) (x, T) + in (mark_bound_abs xT, subst_bound (mark_bound_body xT, t)) end; fun abs_ast_tr' asts = (case Ast.unfold_ast_p "_abs" (Ast.Appl (Ast.Constant "_abs" :: asts)) of From lukas.stevens+isabelle-users at in.tum.de Fri Jul 10 17:11:30 2026 From: lukas.stevens+isabelle-users at in.tum.de (Lukas Stevens) Date: Fri, 10 Jul 2026 17:11:30 +0200 Subject: Printing of dummy terms in syntax translations In-Reply-To: <66c78c92-a3fd-4e67-ad8e-52abef215f93@in.tum.de> References: <66c78c92-a3fd-4e67-ad8e-52abef215f93@in.tum.de> Message-ID: <769bf895-70b9-467d-ba10-3b383dd2fdb3@in.tum.de> After consulting with Tobias and Larry, I have now inspected all users of Syntax_Trans.atomic_abs_tr' in the distribution and the AFP and propose the attached changes. Except for a change in HOL-Probability.Probability_Measure all changes are concerned with the print_translation of Collect in HOL.Set and its clones. The change to the print translation of Collect is necessary, since Syntax_Trans.atomic_abs_tr' now might return _idtdummy instead of always a variable. This changes the behavior of term "{_. True}" from outputting "{uu_. True}" to "{_. True}", which is arguably nicer. The change to HOL-Probability.Probability_Measure is perhaps overly defensive because the translation only works on bounded set comprehensions: e.g., for a bounded set comprehension {x. x ∈ A ∧ True} the bound variable x is always used, so it can never be replaced by a dummy. Allowing dummies in bounded set comprehensions would therefore require significant refinements. I have checked all other users of Syntax_Trans.atomic_abs_tr' and convinced myself that no changes are necessary. The AFP builds successfully with these changes: https://build.proof.cit.tum.de/build?id=38dc54fc-0a32-4755-a0b3-496107c8d016. Tobias has pointed out that he is the original author of the file, but judging from the more recent history Makarius is the current owner of the file. Makarius, can you comment on how to proceed? Cheers, Lukas On 07.07.26 13:09, Lukas Stevens wrote: > Dear Isabelle developers, > > I am working on the type annotation algorithm in > ~~/src/HOL/Tools/Sledgehammer/sledgehammer_isar_annotate.ML that is > used by some interactive tools, e.g., Sledgehammer and Sketch and > Explore. The algorithm places type annotations in terms such that > printing and then parsing them again yields a term with the same type > as the original term. This is crucial when trying to output > well-formed Isar proofs. > > While testing the algorithm, I ran into some unfortunate behavior that > results from the interaction of Syntax_Trans.atomic_abs_tr' and the > syntax translation case_prod_tr'/case_prod_guess_names_tr' in > Product_Type.thy. You can observe this behavior in > Isabelle/333ffbe82f5f, where > >   term "λ_. 1 :: nat" > > yields "λ_. 1" :: "'a ⇒ nat" while > >   term "λ(x, _). 1 :: nat" > > gives "λ(x, uu_). 1" :: "'a × 'b ⇒ nat", which contains an internal > variable uu_. The latter term cannot be parsed after printing it due > to the internal variable. Note that the same behavior surfaces for > other users of Syntax_Trans.atomic_abs_tr' such as the translations > for SOME and set comprehensions. > > The reason for the first term being printed without internal variables > is the changeset Isabelle/41986849fee0 that adds support for the > syntax constant _idtdummy (printed as _) to > Syntax_Trans.abs_tr'/mk_binder_tr'; however, > case_prod_tr'/case_prod_guess_names_tr' internally uses > Syntax_Trans.atomic_abs_tr', which has no support for _idtdummy. This > could be changed by a 4-line modification of > Syntax_Trans.atomic_abs_tr' (see attached diff), which produces the > right result on the surface, although I am not sure if there is any > collateral. > > Anecdotally, I know that users of Sketch and Explore have stumbled > over this behavior. > > Cheers, > > Lukas > > > -------------- next part -------------- diff -r 333ffbe82f5f src/HOL/Probability/Probability_Measure.thy --- a/src/HOL/Probability/Probability_Measure.thy Mon Jul 06 15:47:01 2026 +0200 +++ b/src/HOL/Probability/Probability_Measure.thy Fri Jul 10 14:22:56 2026 +0200 @@ -300,9 +300,11 @@ end | go pattern elem (Abs abs) = let - val (x as (_ $ tx), t) = Syntax_Trans.atomic_abs_tr' ctxt abs + val (x, t) = Syntax_Trans.atomic_abs_tr' ctxt abs in - go ((x, 0) :: pattern) (bound_dummyT $ tx :: elem) t + case x of + _ $ tx => go ((x, 0) :: pattern) (tx :: elem) t + | _ => raise Match end | go pattern elem (Const (\<^const_syntax>\case_prod\, _) $ t) = go diff -r 333ffbe82f5f src/HOL/Set.thy --- a/src/HOL/Set.thy Mon Jul 06 15:47:01 2026 +0200 +++ b/src/HOL/Set.thy Fri Jul 10 14:22:56 2026 +0200 @@ -353,14 +353,15 @@ if check (P, 0) then tr' P else let - val (x as _ $ Free(xN, _), t) = Syntax_Trans.atomic_abs_tr' ctxt abs; + val (x, t) = Syntax_Trans.atomic_abs_tr' ctxt abs; val M = Syntax.const \<^syntax_const>\_Coll\ $ x $ t; in - case t of - Const (\<^const_syntax>\HOL.conj\, _) $ - (Const (\<^const_syntax>\Set.member\, _) $ - (Const (\<^syntax_const>\_bound\, _) $ Free (yN, _)) $ A) $ P => - if xN = yN then Syntax.const \<^syntax_const>\_Collect\ $ x $ A $ P else M + case (x, t) of + (_ $ Free(xN, _), + Const (\<^const_syntax>\HOL.conj\, _) $ + (Const (\<^const_syntax>\Set.member\, _) $ + (Const (\<^syntax_const>\_bound\, _) $ Free (yN, _)) $ A) $ P) => + if xN = yN then Syntax.const \<^syntax_const>\_Collect\ $ x $ A $ P else M | _ => M end end; diff -r 333ffbe82f5f src/Pure/Syntax/syntax_trans.ML --- a/src/Pure/Syntax/syntax_trans.ML Mon Jul 06 15:47:01 2026 +0200 +++ b/src/Pure/Syntax/syntax_trans.ML Fri Jul 10 14:22:56 2026 +0200 @@ -345,8 +345,11 @@ (strip_abss ctxt strip_abs_vars strip_abs_body (eta_contr ctxt tm)); fun atomic_abs_tr' ctxt (x, T, t) = - let val xT = singleton (variant_bounds ctxt t) (x, T) - in (mark_bound_abs xT, subst_bound (mark_bound_body xT, t)) end; + if Name.is_internal x andalso not (Term.is_dependent t) then + (Const ("_idtdummy", T), incr_boundvars ~1 t) + else + let val xT = singleton (variant_bounds ctxt t) (x, T) + in (mark_bound_abs xT, subst_bound (mark_bound_body xT, t)) end; fun abs_ast_tr' asts = (case Ast.unfold_ast_p "_abs" (Ast.Appl (Ast.Constant "_abs" :: asts)) of -------------- next part -------------- diff -r dd0ea2723c32 thys/Regular_Tree_Relations/Util/FSet_Utils.thy --- a/thys/Regular_Tree_Relations/Util/FSet_Utils.thy Mon Jul 06 15:47:06 2026 +0200 +++ b/thys/Regular_Tree_Relations/Util/FSet_Utils.thy Fri Jul 10 14:09:57 2026 +0200 @@ -92,14 +92,15 @@ if check (P, 0) then tr' P else let - val (x as _ $ Free(xN, _), t) = Syntax_Trans.atomic_abs_tr' ctxt abs; + val (x, t) = Syntax_Trans.atomic_abs_tr' ctxt abs; val M = Syntax.const \<^syntax_const>\_fColl\ $ x $ t; in - case t of - Const (\<^const_syntax>\HOL.conj\, _) $ - (Const (\<^const_syntax>\fmember\, _) $ - (Const (\<^syntax_const>\_bound\, _) $ Free (yN, _)) $ A) $ P => - if xN = yN then Syntax.const \<^syntax_const>\_fCollect\ $ x $ A $ P else M + case (x, t) of + (_ $ Free(xN, _), + Const (\<^const_syntax>\HOL.conj\, _) $ + (Const (\<^const_syntax>\fmember\, _) $ + (Const (\<^syntax_const>\_bound\, _) $ Free (yN, _)) $ A) $ P) => + if xN = yN then Syntax.const \<^syntax_const>\_fCollect\ $ x $ A $ P else M | _ => M end end; diff -r dd0ea2723c32 thys/Zippy/Zippy/Instances/Zip/Examples/Benchmarks/Set.thy --- a/thys/Zippy/Zippy/Instances/Zip/Examples/Benchmarks/Set.thy Mon Jul 06 15:47:06 2026 +0200 +++ b/thys/Zippy/Zippy/Instances/Zip/Examples/Benchmarks/Set.thy Fri Jul 10 14:09:57 2026 +0200 @@ -350,14 +350,15 @@ if check (P, 0) then tr' P else let - val (x as _ $ Free(xN, _), t) = Syntax_Trans.atomic_abs_tr' ctxt abs; + val (x, t) = Syntax_Trans.atomic_abs_tr' ctxt abs; val M = Syntax.const \<^syntax_const>\_Coll\ $ x $ t; in - case t of - Const (\<^const_syntax>\HOL.conj\, _) $ - (Const (\<^const_syntax>\Set.member\, _) $ - (Const (\<^syntax_const>\_bound\, _) $ Free (yN, _)) $ A) $ P => - if xN = yN then Syntax.const \<^syntax_const>\_Collect\ $ x $ A $ P else M + case (x, t) of + (_ $ Free(xN, _), + Const (\<^const_syntax>\HOL.conj\, _) $ + (Const (\<^const_syntax>\Set.member\, _) $ + (Const (\<^syntax_const>\_bound\, _) $ Free (yN, _)) $ A) $ P) => + if xN = yN then Syntax.const \<^syntax_const>\_Collect\ $ x $ A $ P else M | _ => M end end; From makarius at sketis.net Fri Jul 10 20:00:14 2026 From: makarius at sketis.net (Makarius) Date: Fri, 10 Jul 2026 20:00:14 +0200 Subject: Printing of dummy terms in syntax translations In-Reply-To: <769bf895-70b9-467d-ba10-3b383dd2fdb3@in.tum.de> References: <66c78c92-a3fd-4e67-ad8e-52abef215f93@in.tum.de> <769bf895-70b9-467d-ba10-3b383dd2fdb3@in.tum.de> Message-ID: On 10/07/2026 17:11, Lukas Stevens wrote: > > Tobias has pointed out that he is the original author of the file, but judging > from the more recent history Makarius is the current owner of the file. > Makarius, can you comment on how to proceed? Tobias started the inner syntax engine > 30 years ago. I have reworked it so many times since then that I don't remember how often it has changed. In Isabelle development, we don't have "owners" of anything, but individuals who are personally responsible for certain parts of the system. I am personally responsible for everything around inner syntax. I am presently busy elsewhere, and my mail folder is lagging behind several months. Re-openening a thread just after a few days of inactivity is a waste of time --- it slows down the development process for no particular reason. Makarius From makarius at sketis.net Tue Jul 14 11:59:54 2026 From: makarius at sketis.net (Makarius) Date: Tue, 14 Jul 2026 11:59:54 +0200 Subject: [isabelle] Isabelle theory name clash In-Reply-To: References: <85b93227-7c01-4b24-9169-240515582f97@in.tum.de> Message-ID: On 13/07/2026 12:46, Lawrence Paulson wrote: > This is a tough ons, but we need a migration plan to make theory names local > to sessions somehow. We have that already. See this NEWS entry from Isabelle2017 (October 2017): """ * Theory names are qualified by the session name that they belong to. This affects imports, but not the theory name space prefix (which is just the theory base name as before). """ The remaining problem are the internal name spaces of theories. It will work properly "one happy day in the near future". One problem here is that we have more and more funny Isabelle/ML tools doing odd things with internal names. Thus it becomes increasingly difficult to cleanup things. It will happen nonetheless, eventually. Makarius From makarius at sketis.net Tue Jul 14 23:27:33 2026 From: makarius at sketis.net (Makarius) Date: Tue, 14 Jul 2026 23:27:33 +0200 Subject: NEWS: Poly/ML 64_32 heap size 32 GiB instead of 16 GiB Message-ID: *** System *** * Poly/ML 5.9.2 has been patched to support larger heap size in the special x86_64_32/arm64_32 mode with 32-bit values: the limit is now 32 GiB, instead of 16 GiB before. The cost is a factor of 1.2 .. 1.5 more memory requirement (due to alignment of values), and a slowdown factor 0.9 .. 0.95 for average sessions. For very large sessions, the gain is a speedup factor 1.9 .. 1.2, due to reduced GC time. It also avoids the need for bulky x86_64/arm64 mode with 64-bit values and excessive GC time. This refers to Isabelle/e3c3e01d3eb1. This is the result of significant work by David Matthews in collaboration with Martin Desharnais-Schäfer. The plan is to use the enlarged 64_32 memory model as "one size fits for almost all applications", and omit the old 64_32 mode with 16 GiB that is in principle still supported by Poly/ML. The full 64-bit mode is available as before, but discouraged. Its known GC performance problems will be addressed at a later stage. (Not now and not for this release.) Makarius From makarius at sketis.net Tue Jul 14 23:35:22 2026 From: makarius at sketis.net (Makarius) Date: Tue, 14 Jul 2026 23:35:22 +0200 Subject: NEWS: Poly/ML 64_32 heap size 32 GiB instead of 16 GiB In-Reply-To: References: Message-ID: On 14/07/2026 23:31, Lawrence Paulson wrote: > Could this be used with Isabelle 2025-2? Maybe. We have not tried it. Isabelle development is linear, moving forward on a single branch, or rather no branches at all. Makarius From makarius at sketis.net Tue Jul 14 23:43:52 2026 From: makarius at sketis.net (Makarius) Date: Tue, 14 Jul 2026 23:43:52 +0200 Subject: NEWS: Poly/ML 64_32 heap size 32 GiB instead of 16 GiB In-Reply-To: References: Message-ID: <50af5ada-3a16-408b-bf91-1de7b166d942@sketis.net> Here are some measurements from a few days ago: https://files.sketis.net/build_profiling_11-Jul-2026 This has been produced with a command-line like this: isabelle build_profiling -A: Automated_Stateful_Protocol_Verification Bicategory CZH_Universal_Constructions Category3 Frequency_Moments JinjaThreads MiniSail ResiduatedTransitionSystem2 Two_Hermitian_Results HOL-Probability The "isabelle build_profiling" tool is for administrative purposes, which explains its lack of documentation in the "system" manual. It is so useful, that I might make it more official for the coming release, with proper documentation. The above test sessions are mainly those that hit the former 16 GiB limit, which explains why the speedup is quite good. Various other sessions, e.g. requirements of the main tests, need much less ML heap: here we see a small slowdown and increase of stored heap size. I do hope that slowdown and increased heap images are not significant in practice, so that we can proceed with the plan to have just one main Poly/ML configuration. Makarius From makarius at sketis.net Wed Jul 15 00:07:42 2026 From: makarius at sketis.net (Makarius) Date: Wed, 15 Jul 2026 00:07:42 +0200 Subject: NEWS: Separate application bundles for "macos" (Intel) vs. "macos_arm" (Apple Silicon) Message-ID: *** General *** * The Isabelle application bundle has been split into "macos" (x86_64-darwin, Intel) and "macos_arm (arm64-darwin, Apple Silicon). The correct version needs to be used for the actual system platform: emulated Java via Rosetta 2 is explicitly excluded. Isabelle add-on tools usually work on arm64-darwin, with the notable exception of the z3 prover --- z3 uses x86_64-darwin and thus requires Rosetta 2, as long as that is still provided by Apple. This refers to Isabelle/ca65aeef65f0. Here is the complete list of remaining x86_64 tools: - z3 (stuck with a very old side-branch of the sources) - nunchaku + smbc (considered "experimental", not used in applications) The list used to have further entries, but they are now native on arm64: - spass-3.8ds: after closer inspection, I managed to re-build it on all current platforms (see also "isabelle component_spass" in Isabelle/272abac962eb and preceeding changes). - vampire-4.8: that is a dead side-branch before current vampire-5, specifically for Isabelle ("HO" + "sledgehammer"). I was rather lucky to rebuild it for arm64-darwin on one of my old macOS installations: actually a cross-compile from Intel, which explains minor misunderstandings in the changelog of Isabelle/8eee497c7252). That's finally it for the coming Isabelle release. Note that next year's macOS release will no longer support arm64 + x86_64 side-by-side. (The "27" release of 2026 still does, despite the confusion of numbers.) Makarius From makarius at sketis.net Wed Jul 15 00:23:44 2026 From: makarius at sketis.net (Makarius) Date: Wed, 15 Jul 2026 00:23:44 +0200 Subject: Plan for Isabelle2026 (October 2026) Message-ID: <29bec495-d4b0-46cd-9c91-bddeaacd2f2c@sketis.net> As a reminder, here is the given plan for the coming release https://sketis.net/2025/plan-for-isabelle2026-october-2026 (posted 17-Dec-2025). Nobody has disagreed with that. So hopefully everybody agrees with it, and understands the consequences. Makarius From makarius at sketis.net Wed Jul 15 00:30:52 2026 From: makarius at sketis.net (Makarius) Date: Wed, 15 Jul 2026 00:30:52 +0200 Subject: NEWS: Separate application bundles for "macos" (Intel) vs. "macos_arm" (Apple Silicon) In-Reply-To: References: Message-ID: <31296f9d-5103-4dd7-89da-9bbede6de1f4@sketis.net> On 15/07/2026 00:07, Makarius wrote: > > The list used to have further entries, but they are now native on arm64: > >   - spass-3.8ds: after closer inspection, I managed to re-build it on all > current platforms (see also "isabelle component_spass" in > Isabelle/272abac962eb and preceeding changes). > >   - vampire-4.8: that is a dead side-branch before current vampire-5, > specifically for Isabelle ("HO" + "sledgehammer"). I was rather lucky to > rebuild it for arm64-darwin on one of my old macOS installations: actually a > cross-compile from Intel, which explains minor misunderstandings in the > changelog of Isabelle/8eee497c7252). One more entry: - zipperposition-2.1: I managed to tinker with opam-2.2.1 instead of our usual opam-2.0.7, see also Isabelle/85ee34305702. We are stuck with opam-2.0.7, the last version that was available for Cygwin. Later opam-2.2.1 theoretically supports Windows better, via Msys2 instead of Cygwin, but I did not quite manage to make it work for us. The OCaml ecosystem is generally a bit fragile an not quite portable. Makarius