From huch at in.tum.de Wed Oct 2 13:21:37 2024 From: huch at in.tum.de (Fabian Huch) Date: Wed, 2 Oct 2024 13:21:37 +0200 Subject: [isabelle-dev] Brief TUM server outage Message-ID: <5bb4c556-a432-4f23-bbd4-59ba6263a46b@in.tum.de> We will have a brief server outage today for BIOS updates. Fabian From makarius at sketis.net Thu Oct 10 14:25:42 2024 From: makarius at sketis.net (Makarius) Date: Thu, 10 Oct 2024 14:25:42 +0200 Subject: [isabelle-dev] NEWS: Inner-syntax markup and declaration bundles Message-ID: <49229ded-0022-409e-a7fa-a7d57f1957fe@sketis.net> *** General *** * Command "unbundle b" and its variants like "context includes b" allow an optional name prefix with the reserved word "no": "unbundle no b" etc. This inverts the polarity of bundled declarations like 'notation' vs. 'no_notation', and thus avoids redundant bundle definitions like "foobar_syntax" vs. "no_foobar_syntax", because "no foobar_syntax" may be used instead. Consequently, the syntax for multiple bundle names has been changed slightly, demanding an explicit 'and' keyword. Minor INCOMPATIBILITY. * Command "open_bundle b" is like "bundle b" followed by "unbundle b", so its declarations are applied immediately, but also named for later re-use: "unbundle no b" etc. * Blocks for pretty-printing (of types, terms, props etc.) now support properties "open_block" (bool) and "notation" (string as cartouche). When "open_block" is enabled, the block has no impact on formatting, but it may carry markup information via "notation". The latter uses formal kinds (e.g. "mixfix", "infix", "binder") together with informal words to describe the notation. This markup affects both input and output of inner syntax --- it can be explored via mouse hovering in the Prover IDE as usual (or programmatically by Isabelle/Scala tools). Markup for "infix" and "binder" declarations are automatic, but general mixfix forms require manual annotations in the theory library. Plenty of existing examples may be found in the Isabelle sources by searching for "notation=" (without quotes and no extra space). Occasional INCOMPATIBILITY for 'no_syntax' or 'no_notation' declarations in user applications: the mixfix template needs to be adapted accordingly, but it is often better to use "unbundle no foobar_syntax", as explained for HOL libraries below. * Inner syntax translations now support formal dependencies via commands 'syntax_types' or 'syntax_consts'. This is essentially an abstract specification of the effect of 'translations' (or translation functions in ML). Most Isabelle theories have been adapted accordingly, such that hyperlinks work properly e.g. for "['a, 'b] ⇒ 'c" or "⟦A; B⟧ ⟹ C" in Pure, and "∀x∈A. B x" or "∃x∈A. B x" in HOL. *** HOL *** * Various declaration bundles support adhoc modification of notation, notably like this: unbundle no list_syntax unbundle no list_enumeration_syntax unbundle no list_comprehension_syntax unbundle no relcomp_syntax unbundle no converse_syntax unbundle no rtrancl_syntax unbundle no trancl_syntax unbundle no reflcl_syntax unbundle no abs_syntax unbundle no floor_ceiling_syntax unbundle no uminus_syntax unbundle no funcset_syntax This is more robust than individual 'no_syntax' / 'no_notation' commands, which need to copy mixfix declarations from elsewhere and thus break after changes in the library. * Theory "HOL-Library.Datatype_Records" provides bundle "datatype_record_syntax" to exchange its alternative notation versus regular "record_syntax". This also allows to swap record syntax later on, notably like this: unbundle no datatype_record_syntax This refers to Isabelle/87f173836d56 and AFP/68a8276e79a0. Makarius From lp15 at cam.ac.uk Thu Oct 10 14:38:31 2024 From: lp15 at cam.ac.uk (Lawrence Paulson) Date: Thu, 10 Oct 2024 12:38:31 +0000 Subject: [isabelle-dev] NEWS: Inner-syntax markup and declaration bundles In-Reply-To: <49229ded-0022-409e-a7fa-a7d57f1957fe@sketis.net> References: <49229ded-0022-409e-a7fa-a7d57f1957fe@sketis.net> Message-ID: <97609680-D33F-4B08-951A-9633F6F11E52@cam.ac.uk> And welcome for that reason. Thanks! Larry > On 10 Oct 2024, at 13:25, Makarius wrote: > > This is more robust than individual 'no_syntax' / 'no_notation' > commands, which need to copy mixfix declarations from elsewhere and thus > break after changes in the library. From makarius at sketis.net Thu Oct 10 15:22:14 2024 From: makarius at sketis.net (Makarius) Date: Thu, 10 Oct 2024 15:22:14 +0200 Subject: [isabelle-dev] NEWS: Inner-syntax markup and declaration bundles In-Reply-To: <49229ded-0022-409e-a7fa-a7d57f1957fe@sketis.net> References: <49229ded-0022-409e-a7fa-a7d57f1957fe@sketis.net> Message-ID: On 10/10/2024 14:25, Makarius wrote: > > * Blocks for pretty-printing (of types, terms, props etc.) now support > properties "open_block" (bool) and "notation" (string as cartouche). > When "open_block" is enabled, the block has no impact on formatting, but > it may carry markup information via "notation". The latter uses formal > kinds (e.g. "mixfix", "infix", "binder") together with informal words to > describe the notation. This markup affects both input and output of > inner syntax --- it can be explored via mouse hovering in the Prover IDE > as usual (or programmatically by Isabelle/Scala tools). Markup for > "infix" and "binder" declarations are automatic, but general mixfix > forms require manual annotations in the theory library. Plenty of > existing examples may be found in the Isabelle sources by searching for > "notation=" (without quotes and no extra space). Occasional > INCOMPATIBILITY for 'no_syntax' or 'no_notation' declarations in user > applications: the mixfix template needs to be adapted accordingly, but > it is often better to use "unbundle no foobar_syntax", as explained for > HOL libraries below. Some more remarks on this. Markup for pretty-blocks (or quasi blocks via "open_block") replaces the old TODO-item of "markup of sub-expressions of types/terms/blocks". The latter turned out as too complex to be ever implemented, especially due to very ambitious syntax translations that have emerged over the decades in applications. Doing it on the surface of the inner-syntax instead, merely required some "minor" cleanup and manual annotations of free-form mixfix syntax (not infix nor binder). I have mostly done it for the main Isabelle library theories already: HOL, HOL-Library, HOL-Algebra, HOL-Number_Theory, HOL-Analysis etc. More isolated applications are missing, as well as most of AFP. Some important inner-syntax idioms --- e.g. monad syntax and Hoare-logic syntax --- still require further refinement. Ultimately, there should be just one well-understood and uniform approach to it, not 3 different approaches to 7 different versions monads or Hoare logic. Makarius From makarius at sketis.net Thu Oct 10 15:36:24 2024 From: makarius at sketis.net (Makarius) Date: Thu, 10 Oct 2024 15:36:24 +0200 Subject: [isabelle-dev] NEWS: Inner-syntax markup and declaration bundles In-Reply-To: <49229ded-0022-409e-a7fa-a7d57f1957fe@sketis.net> References: <49229ded-0022-409e-a7fa-a7d57f1957fe@sketis.net> Message-ID: On 10/10/2024 14:25, Makarius wrote: > > This markup affects both input and output of > inner syntax --- it can be explored via mouse hovering in the Prover IDE > as usual (or programmatically by Isabelle/Scala tools). Further side-remarks: * "output" means that I have reworked to Pretty-printing engine quite a bit, to be more robust and scalable for tons of markup (lets say many MB up to few GB). * "input" means that I have applied approx. 60 small changes to src/Pure/Syntax/parser.ML in order to have markup treated properly within the regular Earley algorithm. I have discovered and removed various oddities in the implementation, but did not understand all of its secrets. As usual, the empiric test material was AFP (including performance). The markup for input was specifically requested by people from Linz, as a prerequisite to make an "accessible" Prover IDE eventually. It means that users without eyesight can explore types/terms/props by a tactile interface. (A few years ago VSCode had made quite some noise about "accessibility", but that has degraded a lot recently, so it is not an immediate answer to the problem.) Makarius From makarius at sketis.net Thu Oct 10 16:32:20 2024 From: makarius at sketis.net (Makarius) Date: Thu, 10 Oct 2024 16:32:20 +0200 Subject: [isabelle-dev] NEWS: Inner-syntax markup and declaration bundles In-Reply-To: References: <49229ded-0022-409e-a7fa-a7d57f1957fe@sketis.net> Message-ID: On 10/10/2024 15:36, Makarius wrote: > > The markup for input was specifically requested by people from Linz, as a > prerequisite to make an "accessible" Prover IDE eventually. It means that > users without eyesight can explore types/terms/props by a tactile interface. > (A few years ago VSCode had made quite some noise about "accessibility", but > that has degraded a lot recently, so it is not an immediate answer to the > problem.) Side-remark on this side-remark. From what I've learned in Linz 1 year ago, the main Open-Source product in this area is NVDA https://www.nvaccess.org (for Windows only). The editor, whatever it is, needs to connect to that. There is even an official accessibility API Java, but I don't know if and how that works. Makarius From makarius at sketis.net Thu Oct 10 20:16:37 2024 From: makarius at sketis.net (Makarius) Date: Thu, 10 Oct 2024 20:16:37 +0200 Subject: [isabelle-dev] Remaining uses of show_brackets Message-ID: Are there any remaining uses of show_brackets? Here is historical proof for this feature from many decades ago: changeset: 504:a4f09493d929 user: nipkow date: Tue Aug 02 09:07:10 1994 +0200 files: src/Pure/Syntax/printer.ML description: added flag show_brackets for printinmg fully bracketed terms. changeset: 508:d8b6999ca364 user: lcp date: Thu Aug 04 11:51:30 1994 +0200 files: doc-src/Ref/introduction.tex description: addition of show_brackets The documentation in d8b6999ca364 says: "show_brackets makes Isabelle show full bracketing. This reveals the grouping of infix operators." We have that already via PIDE markup for pretty-blocks, see also Isabelle/87f173836d56 --- and it works more accurately, too. So if there are no further uses of it, I will remove it shortly before the Isabelle2025 release process starts (Jan-2025). Makarius From lp15 at cam.ac.uk Thu Oct 10 20:26:54 2024 From: lp15 at cam.ac.uk (Lawrence Paulson) Date: Thu, 10 Oct 2024 18:26:54 +0000 Subject: [isabelle-dev] Remaining uses of show_brackets In-Reply-To: References: Message-ID: Yes – for anyone who wants their proof states to be legible. I always recommend it to students. It’s exactly the same principle as having [_,_,_] for lists instead of _::_::_::nil. Larry > On 10 Oct 2024, at 19:16, Makarius wrote: > > Are there any remaining uses of show_brackets? From makarius at sketis.net Thu Oct 10 20:51:09 2024 From: makarius at sketis.net (Makarius) Date: Thu, 10 Oct 2024 20:51:09 +0200 Subject: [isabelle-dev] Remaining uses of show_brackets In-Reply-To: References: Message-ID: On 10/10/2024 20:26, Lawrence Paulson wrote: > Yes – for anyone who wants their proof states to be legible. I always recommend it to students. I don't understand what you mean by "legible". How is the following example legible? declare [[show_brackets]] lemma ‹∀x y. P x y ⟶ Q y x› goal (1 subgoal): 1. (∀(x y). ((P x y) ⟶ (Q y x))) The parentheses for the variable bindings are even wrong in the sense of the formal syntax. > It’s exactly the same principle as having [_,_,_] for lists instead of _::_::_::nil. I don't understand that either. Can you explain that, please? If I would understand the principle, I could say if cane be done via PIDE rendering instead of occasionally bad parentheses. Makarius From lammich at in.tum.de Thu Oct 10 21:19:14 2024 From: lammich at in.tum.de (Peter Lammich) Date: Thu, 10 Oct 2024 21:19:14 +0200 Subject: [isabelle-dev] Remaining uses of show_brackets In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: From lp15 at cam.ac.uk Thu Oct 10 22:48:52 2024 From: lp15 at cam.ac.uk (Lawrence Paulson) Date: Thu, 10 Oct 2024 20:48:52 +0000 Subject: [isabelle-dev] Remaining uses of show_brackets In-Reply-To: References: Message-ID: Oh, that one. I quite forgot it was there. But it’s occasionally useful when you aren’t sure about operator precedences. Is it hard to support? Larry > On 10 Oct 2024, at 19:51, Makarius wrote: > > I don't understand what you mean by "legible". How is the following example legible? > > declare [[show_brackets]] > lemma ‹∀x y. P x y ⟶ Q y x› > > goal (1 subgoal): > 1. (∀(x y). ((P x y) ⟶ (Q y x))) > From lp15 at cam.ac.uk Thu Oct 10 22:49:28 2024 From: lp15 at cam.ac.uk (Lawrence Paulson) Date: Thu, 10 Oct 2024 20:49:28 +0000 Subject: [isabelle-dev] Remaining uses of show_brackets In-Reply-To: References: Message-ID: Yes – exactly and especially when implications are nested. Larry > On 10 Oct 2024, at 20:19, Peter Lammich wrote: > > I think here's a confusion between the attribute that shows all parentheses and the print mode that switches printing of premises from a==>b==>... to [|a;b;...|]==> > > Please do not remove the latter, as it has many users. It makes long subgoals more readable, as you don't have to find the last==> to interpret the goal. > From makarius at sketis.net Fri Oct 11 10:13:31 2024 From: makarius at sketis.net (Makarius) Date: Fri, 11 Oct 2024 10:13:31 +0200 Subject: [isabelle-dev] Remaining uses of show_brackets In-Reply-To: References: Message-ID: <9d53088c-0fef-44b5-89b0-29f40eb9ab3f@sketis.net> >> On 10 Oct 2024, at 19:51, Makarius wrote: >> >> I don't understand what you mean by "legible". How is the following example legible? >> >> declare [[show_brackets]] >> lemma ‹∀x y. P x y ⟶ Q y x› >> >> goal (1 subgoal): >> 1. (∀(x y). ((P x y) ⟶ (Q y x))) On 10/10/2024 22:48, Lawrence Paulson wrote: > Oh, that one. I quite forgot it was there. But it’s occasionally useful when you aren’t sure about operator precedences. Is it hard to support? It is a totally adhoc feature from 30 years ago, and incorrect in certain situations. Can you try if the new mixfix markup works sufficiently well to replace this idea? The new scheme works for parsed input source and pretty-printed output. You just C-hover over the text, and get feedback about its inner-syntax structure. People might call that a "parse tree", but it is better than a raw parse tree (which contains a lot of irrelevant information). Makarius From makarius at sketis.net Fri Oct 11 10:15:36 2024 From: makarius at sketis.net (Makarius) Date: Fri, 11 Oct 2024 10:15:36 +0200 Subject: [isabelle-dev] Remaining uses of show_brackets In-Reply-To: References: Message-ID: <0db58400-93dd-43d0-8bbb-18dc1074b948@sketis.net> On 10/10/2024 21:19, Peter Lammich wrote: > I think here's a confusion between the attribute that shows all parentheses > and the print mode that switches printing of premises from a==>b==>... to > [|a;b;...|]==> > > Please do not remove the latter, as it has many users. It makes long subgoals > more readable, as you don't have to find the last==> to interpret the goal. That is unrelated to the current thread. The time to ask about its "remaining uses" it not there yet, but it will come when the proof state output has been warped 20 yeards foreward. (That is not going to happen for Isabelle2025.) Makarius From lammich at in.tum.de Fri Oct 11 10:45:16 2024 From: lammich at in.tum.de (Peter Lammich) Date: Fri, 11 Oct 2024 10:45:16 +0200 Subject: [isabelle-dev] Remaining uses of show_brackets In-Reply-To: <9d53088c-0fef-44b5-89b0-29f40eb9ab3f@sketis.net> References: <9d53088c-0fef-44b5-89b0-29f40eb9ab3f@sketis.net> Message-ID: <71dc8faf-984c-4cb5-b146-01cd45714727@in.tum.de> On 11/10/2024 10:13, Makarius wrote: > >> On 10 Oct 2024, at 19:51, Makarius wrote: > >> > >> I don't understand what you mean by "legible". How is the following > example legible? > >> > >> declare [[show_brackets]] > >> lemma ‹∀x y. P x y ⟶ Q y x› > >> > >> goal (1 subgoal): > >> 1. (∀(x y). ((P x y) ⟶ (Q y x))) > > On 10/10/2024 22:48, Lawrence Paulson wrote: >> Oh, that one. I quite forgot it was there. But it’s occasionally >> useful when you aren’t sure about operator precedences. Is it hard to >> support? If I'm unsure about operator precedence, I usually go the other way round: I manually add some parentheses, and see how/if the pretty-printed term changes --   Peter > > It is a totally adhoc feature from 30 years ago, and incorrect in > certain situations. > > Can you try if the new mixfix markup works sufficiently well to > replace this idea? The new scheme works for parsed input source and > pretty-printed output. You just C-hover over the text, and get > feedback about its inner-syntax structure. > > People might call that a "parse tree", but it is better than a raw > parse tree (which contains a lot of irrelevant information). > > >     Makarius > > _______________________________________________ > isabelle-dev mailing list > isabelle-dev at in.tum.de > https://mailman46.in.tum.de/mailman/listinfo/isabelle-dev From lp15 at cam.ac.uk Fri Oct 11 13:41:12 2024 From: lp15 at cam.ac.uk (Lawrence Paulson) Date: Fri, 11 Oct 2024 11:41:12 +0000 Subject: [isabelle-dev] Remaining uses of show_brackets In-Reply-To: <9d53088c-0fef-44b5-89b0-29f40eb9ab3f@sketis.net> References: <9d53088c-0fef-44b5-89b0-29f40eb9ab3f@sketis.net> Message-ID: I tried it on a set comprehension and got notation: mixfix "set comprehension” This is pretty useful, because in the past there was no way to examine non-trivial syntax constructions, which in some cases were a complete mystery. If it's not too difficult, could it be possible to jump to the original definition? Larry > On 11 Oct 2024, at 09:13, Makarius wrote: > > Can you try if the new mixfix markup works sufficiently well to replace this idea? The new scheme works for parsed input source and pretty-printed output. You just C-hover over the text, and get feedback about its inner-syntax structure. From makarius at sketis.net Fri Oct 11 13:48:29 2024 From: makarius at sketis.net (Makarius) Date: Fri, 11 Oct 2024 13:48:29 +0200 Subject: [isabelle-dev] Remaining uses of show_brackets In-Reply-To: References: <9d53088c-0fef-44b5-89b0-29f40eb9ab3f@sketis.net> Message-ID: On 11/10/2024 13:41, Lawrence Paulson wrote: > I tried it on a set comprehension and got > > notation: mixfix "set comprehension” > > This is pretty useful, because in the past there was no way to examine non-trivial syntax constructions, which in some cases were a complete mystery. > > If it's not too difficult, could it be possible to jump to the original definition? That is also possible: I've actually had that before setting out for all this "notation=..." markup. It is merely a matter of adding 'syntax_consts' declarations, like I've always done for "notation=binder" to imitate regular 'binder' declarations. You can see that e.g. in prop "∀x∈A. P x" A minor disadvantage: the present PIDE rendering sometimes hides markup that is stacked up too ambitiously, and there is no whitespace between tokens to hover over it. So I will keep this on the TODO list to think about further ... Makarius From makarius at sketis.net Fri Oct 11 13:51:54 2024 From: makarius at sketis.net (Makarius) Date: Fri, 11 Oct 2024 13:51:54 +0200 Subject: [isabelle-dev] Remaining uses of show_brackets In-Reply-To: <71dc8faf-984c-4cb5-b146-01cd45714727@in.tum.de> References: <9d53088c-0fef-44b5-89b0-29f40eb9ab3f@sketis.net> <71dc8faf-984c-4cb5-b146-01cd45714727@in.tum.de> Message-ID: <8c8ca99b-0e3c-4bb8-8d35-5c2bf74a9fd6@sketis.net> On 11/10/2024 10:45, Peter Lammich wrote: >> >> On 10/10/2024 22:48, Lawrence Paulson wrote: >>> Oh, that one. I quite forgot it was there. But it’s occasionally useful >>> when you aren’t sure about operator precedences. Is it hard to support? > > If I'm unsure about operator precedence, I usually go the other way round: I > manually add some parentheses, and see how/if the pretty-printed term changes So now is a good oppurtinity to try the new markup scheme of Isabelle/87f173836d56. It can save a lot of time, because things don't have to be printed to see the term structure. Makarius From makarius at sketis.net Wed Oct 16 23:25:58 2024 From: makarius at sketis.net (Makarius) Date: Wed, 16 Oct 2024 23:25:58 +0200 Subject: [isabelle-dev] NEWS: Type constraints for constants (inner syntax printing) Message-ID: <9178d55b-f0a8-43c5-b9df-179114099355@sketis.net> *** General *** * Inner syntax translations now support formal dependencies via commands 'syntax_types' or 'syntax_consts'. This is essentially an abstract specification of the effect of 'translations' (or translation functions in ML). Most Isabelle theories have been adapted accordingly, such that hyperlinks work properly e.g. for "['a, 'b] ⇒ 'c" or "⟦A; B⟧ ⟹ C" in Pure, and "∀x∈A. B x" or "∃x∈A. B x" in HOL. This refers to Isabelle/8e7bd0566759. The key change is Isabelle/26ecbac09941, but it only turned out that simple due to many "changed for change elimination" before it. A few more details are still missing, e.g. type constraints for mixfix delimiters. Makarius From nschirmer at apple.com Thu Oct 17 11:12:49 2024 From: nschirmer at apple.com (Norbert Schirmer) Date: Thu, 17 Oct 2024 11:12:49 +0200 Subject: [isabelle-dev] NEWS: Type constraints for constants (inner syntax printing) In-Reply-To: <9178d55b-f0a8-43c5-b9df-179114099355@sketis.net> References: <9178d55b-f0a8-43c5-b9df-179114099355@sketis.net> Message-ID: <907C46E0-BD0B-41B6-B2EE-C174BD6CE73F@apple.com> Hi Makarius, Thanks a lot for the work. > > *** General *** > > * Inner syntax translations now support formal dependencies via commands > 'syntax_types' or 'syntax_consts'. This is essentially an abstract > specification of the effect of 'translations' (or translation functions > in ML). Most Isabelle theories have been adapted accordingly, such that > hyperlinks work properly e.g. for "['a, 'b] ⇒ 'c" or "⟦A; B⟧ ⟹ C" in > Pure, and "∀x∈A. B x" or "∃x∈A. B x" in HOL. > > This refers to Isabelle/8e7bd0566759. > I guess you wanted to mention this News entry: * Inner syntax printing now supports type constraints for constants: this is guarded by the configuration options "show_consts_markup" (default true) and "show_markup" (default true for PIDE interaction). Ast translation rules (command 'translations') and mixfix notation work with or without such extra constraints, but ML translation functions (command 'print_ast_translation') need may need to be changed slightly. Rare INCOMPATIBILITY. The Prover IDE displays type constraints for constants as for variables, e.g. via C-mouse hovering. > > The key change is Isabelle/26ecbac09941, but it only turned out that simple due to many "changed for change elimination" before it. > > A few more details are still missing, e.g. type constraints for mixfix delimiters. > > Looking forward to it. Regards, Norbert -- Norbert Schirmer (nschirmer at apple.com)  SEG Formal Verification -------------- next part -------------- An HTML attachment was scrubbed... URL: From makarius at sketis.net Fri Oct 18 22:55:59 2024 From: makarius at sketis.net (Makarius) Date: Fri, 18 Oct 2024 22:55:59 +0200 Subject: [isabelle-dev] NEWS: Type constraints for constants (inner syntax printing) In-Reply-To: <907C46E0-BD0B-41B6-B2EE-C174BD6CE73F@apple.com> References: <9178d55b-f0a8-43c5-b9df-179114099355@sketis.net> <907C46E0-BD0B-41B6-B2EE-C174BD6CE73F@apple.com> Message-ID: <2690554a-7d1c-438a-9e63-0b04f0d89f47@sketis.net> On 17/10/2024 11:12, Norbert Schirmer wrote: > I guess you wanted to mention this News entry: > > * Inner syntax printing now supports type constraints for constants: > this is guarded by the configuration options "show_consts_markup" > (default true) and "show_markup" (default true for PIDE interaction). > Ast translation rules (command 'translations') and mixfix notation work > with or without such extra constraints, but ML translation functions > (command 'print_ast_translation') need may need to be changed slightly. > Rare INCOMPATIBILITY. The Prover IDE displays type constraints for > constants as for variables, e.g. via C-mouse hovering. You are right. Here is an updated version: * Inner syntax printing now supports type constraints for constants, optionally with mixfix syntax (infix, binder etc.). This is guarded by the configuration options "show_consts_markup" (default true) and "show_markup" (default true for PIDE interaction). The Prover IDE displays type constraints as usual via C-mouse hovering. Ast translation rules (command 'translations') already work with extra type constraints, but the result omits the type of a matched constant. ML translation functions (command 'print_ast_translation') based on Ast.unfold_ast etc. work in the same manner, but more complex translations may require manual changes: rare INCOMPATIBILITY. See Isabelle/0e27325da568. After so many renovations of the inner-syntax engine, old problems get actually solved, although it has required some decades. Now the situation is again asymmetric, because mixfix consts don't get type constraints on input. Makarius From makarius at sketis.net Mon Oct 21 19:16:43 2024 From: makarius at sketis.net (Makarius) Date: Mon, 21 Oct 2024 19:16:43 +0200 Subject: [isabelle-dev] Build Manager problem Message-ID: <35d6f0f5-ec43-4b72-9772-eafc9165a2ee@sketis.net> We have a problem with the Build Manager database: *** Batch entry 0 INSERT INTO "isabelle_build_sessions" VALUES (('Shadow_DOM'), ('Core_DOM'), ('Pure *** HOL *** HOL-Library *** Core_DOM'), (''), ('1ba926c267c761faab03e3fc034bdd537a6eba09 ... *** '), ('3600000'::int8), ('172459'::int8), ?, ('41e2f25d-19af-41f0-8e90-f50d455f64f8')) was aborted: ERROR: duplicate key value violates unique constraint "isabelle_build_sessions_pkey" *** Detail: Key (name)=(Shadow_DOM) already exists. Call getNextException to see other errors in the batch. https://build.proof.cit.tum.de/build?id=445859c1-0a95-4653-9f47-dc3ba4a75fce Any ideas? Makarius From huch at in.tum.de Mon Oct 21 19:36:50 2024 From: huch at in.tum.de (Fabian Huch) Date: Mon, 21 Oct 2024 19:36:50 +0200 Subject: [isabelle-dev] Build Manager problem In-Reply-To: <35d6f0f5-ec43-4b72-9772-eafc9165a2ee@sketis.net> References: <35d6f0f5-ec43-4b72-9772-eafc9165a2ee@sketis.net> Message-ID: <00daf0ec-080f-4ef2-b871-a6c4b8f0b499@in.tum.de> This means that the build database was left in an undefined state after a previous failure -- in such a case, one can clean it up with: ssh build.proof.cit.tum.de sudo su - build export ISABELLE_IDENTIFIER="build_cluster" isabelle build_process -C -r -f The database is cleaned automatically for every nightly build. Fabian On 10/21/24 19:16, Makarius wrote: > We have a problem with the Build Manager database: > > *** Batch entry 0 INSERT INTO "isabelle_build_sessions" VALUES > (('Shadow_DOM'), ('Core_DOM'), ('Pure > *** HOL > *** HOL-Library > *** Core_DOM'), (''), ('1ba926c267c761faab03e3fc034bdd537a6eba09 > > ... > *** '), ('3600000'::int8), ('172459'::int8), ?, > ('41e2f25d-19af-41f0-8e90-f50d455f64f8')) was aborted: ERROR: > duplicate key value violates unique constraint > "isabelle_build_sessions_pkey" > ***   Detail: Key (name)=(Shadow_DOM) already exists.  Call > getNextException to see other errors in the batch. > > https://build.proof.cit.tum.de/build?id=445859c1-0a95-4653-9f47-dc3ba4a75fce > > > > Any ideas? > > >     Makarius > _______________________________________________ > isabelle-dev mailing list > isabelle-dev at in.tum.de > https://mailman46.in.tum.de/mailman/listinfo/isabelle-dev From makarius at sketis.net Mon Oct 21 19:50:05 2024 From: makarius at sketis.net (Makarius) Date: Mon, 21 Oct 2024 19:50:05 +0200 Subject: [isabelle-dev] Build Manager problem In-Reply-To: <00daf0ec-080f-4ef2-b871-a6c4b8f0b499@in.tum.de> References: <35d6f0f5-ec43-4b72-9772-eafc9165a2ee@sketis.net> <00daf0ec-080f-4ef2-b871-a6c4b8f0b499@in.tum.de> Message-ID: On 21/10/2024 19:36, Fabian Huch wrote: > This means that the build database was left in an undefined state after a > previous failure -- in such a case, one can clean it up with: > > > ssh build.proof.cit.tum.de > > sudo su - build > > export ISABELLE_IDENTIFIER="build_cluster" > > isabelle build_process -C -r -f OK, this works. Makarius From makarius at sketis.net Thu Oct 24 23:29:52 2024 From: makarius at sketis.net (Makarius) Date: Thu, 24 Oct 2024 23:29:52 +0200 Subject: [isabelle-dev] NEWS: Improved strategy for printing term abbreviations Message-ID: <80419f56-4bd4-4d79-a5c2-528d29c2999c@sketis.net> *** General *** * Printing term abbreviations now uses a different strategy: alternate top-down, bottom-up, top-down etc. until a normal form is reached. This is more efficient than the former top-down strategy. It also conforms to AST rewriting (command 'translations'). Rare INCOMPATIBILITY, slightly different results could be printed (often slightly "better" ones). *** ML *** * The new operation Pattern.rewrite_term_yoyo alternates top-down, bottom-up, top-down etc. until a normal form is reached. This often works better than former rewrite_term_top --- that is still available, but has been renamed to rewrite_term_topdown to emphasize that something notable has changed here. This refers to Isabelle/bbed9f218158 and AFP/b347675c7769. I've brushed up the Ast.normalize implementation slightly: it stems from my own Isabelle student project from 3 decades ago (under the informal title of "Rewriting Isabelle"). The current version is here https://isabelle-dev.sketis.net/source/isabelle/browse/default/src/Pure/Syntax/ast.ML;bbed9f218158$227 The corresponding version of Pattern.rewrite_term_yoyo is here https://isabelle-dev.sketis.net/source/isabelle/browse/default/src/Pure/more_pattern.ML;bbed9f218158$57 --- I've changed the typical Berghofer style into more contemporary Haftmann-Wenzel Isabelle/ML, with moderate use of combinators like "perhaps" and "perhaps_loop". The performance of Ast.normalize is still pretty good, even with all these encoded position constraints that we now have in input and output. In performance measurements of Syntax.read_term / string_of_term this part can be usually ignored. The corresponding term normalization operations in Syntax.check_terms / uncheck_terms are much slower, because so many other things are going on here: e.g. somewhat slow type-inference in check_term. The term abbreviations in uncheck_term are now reasonably fast. This is also due to another change is here: https://isabelle-dev.sketis.net/rISABELLEb61abd1e5027 --- it amends earlier attempts on performance tuning for terms with schematic variables, but that had bad consequences for the average situation. I've also revisited the Earley parser recently (for markup), and got the impression that it is rather fast --- after doing only sporadic measurements. We can usually ignore that part in the measurements. In conclusion, here is an example by Hanno Becker (18-Jul-2024 on isabelle-users): abbreviation ‹y x ≡ (x + x)› abbreviation (input) ‹pow3 f t ≡ (f (f (f t)))› abbreviation (input) ‹id0 ≡ pow3 id› abbreviation (input) ‹id1 ≡ pow3 id0› abbreviation (input) ‹id2 ≡ pow3 id1› abbreviation (input) ‹id3 ≡ pow3 id2› abbreviation (input) ‹id4 ≡ pow3 id3› abbreviation (input) ‹id5 ≡ pow3 id4› abbreviation (input) ‹id6 ≡ pow3 id5› term ‹id6 ((0::nat) + 0)› That is now < 0.5s on my 3.6 GHz Intel Linux box from 2017, instead of "seconds on Apple M1". Inflating the term further towards id7 or id8 makes it "seconds" again. If there are more concrete, real world examples, now would be an opportunity to look at performance profiles. Makarius From makarius at sketis.net Sat Oct 26 22:03:50 2024 From: makarius at sketis.net (Makarius) Date: Sat, 26 Oct 2024 22:03:50 +0200 Subject: [isabelle-dev] Failure of AFP/Proof_Strategy_Language Message-ID: <4c009978-6f85-4e6f-9b13-082fb7552327@sketis.net> In Isabelle/d3c0734059ee + AFP/4082096ade5a we have a failure of AFP/Proof_Strategy_Language: Proof_Strategy_Language FAILED (see also "isabelle build_log -H Error Proof_Strategy_Language") *** empty sequence. no proof found. *** At command "find_proof" (line 88 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") *** empty sequence. no proof found. *** At command "find_proof" (line 34 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") *** empty sequence. no proof found. *** At command "find_proof" (line 101 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") *** empty sequence. no proof found. *** At command "find_proof" (line 16 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") *** empty sequence. no proof found. *** At command "find_proof" (line 29 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") *** empty sequence. no proof found. *** At command "find_proof" (line 22 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") The parent Isabelle/0c9075bdff38 appears to be fine, so it is probably due to the changes in Sledgehammer in d3c0734059ee. Makarius From jasmin.blanchette at ifi.lmu.de Mon Oct 28 09:39:29 2024 From: jasmin.blanchette at ifi.lmu.de (Jasmin Blanchette) Date: Mon, 28 Oct 2024 09:39:29 +0100 Subject: [isabelle-dev] Failure of AFP/Proof_Strategy_Language In-Reply-To: <4c009978-6f85-4e6f-9b13-082fb7552327@sketis.net> References: <4c009978-6f85-4e6f-9b13-082fb7552327@sketis.net> Message-ID: <16ED96B2-8786-4CD7-8F8E-8F33E72C7A6B@ifi.lmu.de> Hi Makarius, Yes, my (actually: Lukas Bartl's, under my supervision) change to Sledgehammer (d3c0734059ee) is probably the issue. Sledgehammer is an end user tool. It should be possible to change its output without breaking things. So I'm not a big fan of the "Proof_Strategy_Language" entry's existence in the AFP. But since it's there, maybe we could ask its developer to fix it? Best, Jasmin -- Prof. Dr. Jasmin Blanchette Chair of Theoretical Computer Science and Theorem Proving Ludwig-Maximilians-Universität München Oettingenstr. 67, 80538 München, Germany Tel.: +49 (0)89 2180 9341 Web: https://www.tcs.ifi.lmu.de/mitarbeiter/jasmin-blanchette_de.html > On 26. Oct 2024, at 22:03, Makarius wrote: > > In Isabelle/d3c0734059ee + AFP/4082096ade5a we have a failure of AFP/Proof_Strategy_Language: > > Proof_Strategy_Language FAILED (see also "isabelle build_log -H Error Proof_Strategy_Language") > *** empty sequence. no proof found. > *** At command "find_proof" (line 88 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") > *** empty sequence. no proof found. > *** At command "find_proof" (line 34 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") > *** empty sequence. no proof found. > *** At command "find_proof" (line 101 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") > *** empty sequence. no proof found. > *** At command "find_proof" (line 16 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") > *** empty sequence. no proof found. > *** At command "find_proof" (line 29 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") > *** empty sequence. no proof found. > *** At command "find_proof" (line 22 of "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") > > > The parent Isabelle/0c9075bdff38 appears to be fine, so it is probably due to the changes in Sledgehammer in d3c0734059ee. > > > Makarius > _______________________________________________ > isabelle-dev mailing list > isabelle-dev at in.tum.de > https://mailman46.in.tum.de/mailman/listinfo/isabelle-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4674 bytes Desc: not available URL: From huch at in.tum.de Mon Oct 28 10:38:15 2024 From: huch at in.tum.de (Fabian Huch) Date: Mon, 28 Oct 2024 10:38:15 +0100 Subject: [isabelle-dev] NEWS: Build Manager Message-ID: <1f523f12-09f7-4081-83a3-9e29dadc87a3@in.tum.de> *** System *** * The Build_Manager module has replaced previous glue-code for Jenkins integration. The module contains a server that coordinates continuous integration jobs and user-submitted build tasks and displays them via web front-end. Users can submit tasks in the same manner as with the local build tool, for example:   isabelle build_task -o build_manager_ssh_user=huch -c -A: -a -X slow This requires SSH access to the server and membership in a common Unix group (same requirements as push access to the Isabelle repository). The build manager makes it easy to test any changes *before* a push. To use the build_task command (almost) as a drop-in replacement for isabelle build, trust our TUM signatures by adding the authority to the known hosts (typically in ~/.ssh/known_hosts):   @cert-authority * ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIILPDbJFF8fp35wkNK13f3H4SZEUWokcr65pgQ72S8Je CA at mta And place your ssh user in ~/.isabelle/etc/preferences, e.g.:   build_manager_ssh_user = "huch" A good test (approx. 45 mins) for Isabelle or AFP changes then is:   isabelle build_task -A: -a -X slow Fabian From lammich at in.tum.de Mon Oct 28 10:59:51 2024 From: lammich at in.tum.de (Peter Lammich) Date: Mon, 28 Oct 2024 10:59:51 +0100 Subject: [isabelle-dev] Failure of AFP/Proof_Strategy_Language In-Reply-To: <16ED96B2-8786-4CD7-8F8E-8F33E72C7A6B@ifi.lmu.de> References: <4c009978-6f85-4e6f-9b13-082fb7552327@sketis.net> <16ED96B2-8786-4CD7-8F8E-8F33E72C7A6B@ifi.lmu.de> Message-ID: <1ada7c22-ce23-4856-8bb2-a3423b2d0ef4@in.tum.de> On 28/10/2024 09:39, Jasmin Blanchette wrote: > Hi Makarius, > > Yes, my (actually: Lukas Bartl's, under my supervision) change to > Sledgehammer (d3c0734059ee) is probably the issue. > > Sledgehammer is an end user tool. It should be possible to change its > output without breaking things. So I'm not a big fan of the > "Proof_Strategy_Language" entry's existence in the AFP. But since it's > there, maybe we could ask its developer to fix it? Doesn't sledgehammer have an API? --   Peter > > Best, > Jasmin > > -- > Prof. Dr. Jasmin Blanchette > Chair of Theoretical Computer Science and Theorem Proving > Ludwig-Maximilians-Universität München > Oettingenstr. 67, 80538 München, Germany > Tel.: +49 (0)89 2180 9341 > Web: https://www.tcs.ifi.lmu.de/mitarbeiter/jasmin-blanchette_de.html > > >> On 26. Oct 2024, at 22:03, Makarius wrote: >> >> In Isabelle/d3c0734059ee + AFP/4082096ade5a we have a failure of >> AFP/Proof_Strategy_Language: >> >> Proof_Strategy_Language FAILED (see also "isabelle build_log -H Error >> Proof_Strategy_Language") >> *** empty sequence. no proof found. >> *** At command "find_proof" (line 88 of >> "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") >> *** empty sequence. no proof found. >> *** At command "find_proof" (line 34 of >> "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") >> *** empty sequence. no proof found. >> *** At command "find_proof" (line 101 of >> "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") >> *** empty sequence. no proof found. >> *** At command "find_proof" (line 16 of >> "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") >> *** empty sequence. no proof found. >> *** At command "find_proof" (line 29 of >> "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") >> *** empty sequence. no proof found. >> *** At command "find_proof" (line 22 of >> "~~/dirs/AFP/thys/Proof_Strategy_Language/Example.thy") >> >> >> The parent Isabelle/0c9075bdff38 appears to be fine, so it is >> probably due to the changes in Sledgehammer in d3c0734059ee. >> >> >> Makarius >> _______________________________________________ >> isabelle-dev mailing list >> isabelle-dev at in.tum.de >> https://mailman46.in.tum.de/mailman/listinfo/isabelle-dev > > > _______________________________________________ > isabelle-dev mailing list > isabelle-dev at in.tum.de > https://mailman46.in.tum.de/mailman/listinfo/isabelle-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From huch at in.tum.de Mon Oct 28 11:20:46 2024 From: huch at in.tum.de (Fabian Huch) Date: Mon, 28 Oct 2024 11:20:46 +0100 Subject: [isabelle-dev] Failure of AFP/Proof_Strategy_Language In-Reply-To: <1ada7c22-ce23-4856-8bb2-a3423b2d0ef4@in.tum.de> References: <4c009978-6f85-4e6f-9b13-082fb7552327@sketis.net> <16ED96B2-8786-4CD7-8F8E-8F33E72C7A6B@ifi.lmu.de> <1ada7c22-ce23-4856-8bb2-a3423b2d0ef4@in.tum.de> Message-ID: On 10/28/24 10:59, Peter Lammich wrote: > > > On 28/10/2024 09:39, Jasmin Blanchette wrote: >> Hi Makarius, >> >> Yes, my (actually: Lukas Bartl's, under my supervision) change to >> Sledgehammer (d3c0734059ee) is probably the issue. >> >> Sledgehammer is an end user tool. It should be possible to change its >> output without breaking things. So I'm not a big fan of the >> "Proof_Strategy_Language" entry's existence in the AFP. But since >> it's there, maybe we could ask its developer to fix it? > > Doesn't sledgehammer have an API? > It looks like the entry uses the API, but then prints the output and re-parses it (instead of working with typed data), which is of course bad. Fabian