Dear Manuel,since I am subscribed the isabelle users' mailing list for a couple ofdays now, I can tell you some of the rationales for the designdecisions in quickcheck.Three years ago, I did some profiling of quickcheck's execution andobserved that much time was actually spent constructing anddeconstructing the term representations for printing no matter ifcounterexamples were found or not. For fair comparison betweendifferent testing approaches that all are based on the same codegeneration setup and are quasi-complete, in the sense, if there is acounterexample, it will eventually be found (assuming thecounterexample can be represented as ground term with the given codegeneration setup), the testing performance is essential. The overalltesting performance would render one approach superior or inferior toanother one.Exhaustive generators are more performant than full-exhaustive, but donot allow to print terms when functions are involved.Full_exhaustive generator are less performant but can always print theterms, and hence, are generally more useful.I was always hoping that a lifting and transfer mechanism would allowto transfer the function space of whole theory developments into theAndreas' FinFuns function space and make this automatic transferredcode setup usable for quickcheck. This would make the fast exhaustivegenerators as powerful as the full_exhaustive ones, but (I believe)this development has not happened yet.In practice (thanks to much work on the IDE, non-blocking interactionand use of multiple cores), quickcheck is powerful and useful even ifit is not the slightly optimized version yet.Commonly, the manual and automatic setup for random and exhaustivetesting is done in one go. So both strategies would usually work andstart searching for counterexamples or both would fail, as they relyon the same code generation setup. So then to find counterexamplesquickly, applying one strategy after the other seems awkward, and Ipreferred to implement that multiple strategies can be applied inparallel. As back in 2012, we still had a blocking IDE in wider use,the blocking auto-quickcheck was limited to only one strategy; Idecided for exhaustive testing.Without further investigation of the past, I cannot tell you thereason for the definition of the current Multiset quickcheck setup.Possibly, during some work on the new datatype package or on codegeneration of multisets, some one touched the quickcheck setup, butwas not aware of the quickcheck_generator command---but that's just awild guess from my side; one would really need to look at the relevantchangesets and their context. The multiset theory has quite someevolution since I looked deeply into that file.I hope that helps.Best regards,Lukas

I tried to access the documents but I only get 404 errors.Best BenediktNot FoundThe requested URL /browser_info/current/AFP/Tree_Decomposition/outline.pdf was not found on this server.Apache/2.4.7 (Ubuntu) Server at www.isa-afp.org Port 80> Am 31.05.2016 um 17:24 schrieb Tobias Nipkow :> > Tree Decomposition> Christoph Dittmann> > We formalize tree decompositions and tree width in Isabelle/HOL, proving that trees have treewidth 1. We also show that every edge of a tree decomposition is a separation of the underlying graph. As an application of this theorem we prove that complete graphs of size n have treewidth n-1.> > http://www.isa-afp.org/entries/Tree_Decomposition.shtml> > Enjoy!>

Fixed, sorry, thanks.TobiasOn 01/06/2016 11:09, Benedikt Nordhoff wrote:> I tried to access the documents but I only get 404 errors.>> Best Benedikt> Not Found>> The requested URL /browser_info/current/AFP/Tree_Decomposition/outline.pdf was not found on this server.>> Apache/2.4.7 (Ubuntu) Server at www.isa-afp.org Port 80>>> Am 31.05.2016 um 17:24 schrieb Tobias Nipkow :>>>> Tree Decomposition>> Christoph Dittmann>>>> We formalize tree decompositions and tree width in Isabelle/HOL, proving that trees have treewidth 1. We also show that every edge of a tree decomposition is a separation of the underlying graph. As an application of this theorem we prove that complete graphs of size n have treewidth n-1.>>>> http://www.isa-afp.org/entries/Tree_Decomposition.shtml>>>> Enjoy!>>>

They may simply be referring to the fact that in most cases, once you have recursion, you can define enough number theory for Gdels theorem to apply. The need for termination proofs is quite another matter: accepting a function definition such as f(n) = Suc(f(Suc n)) can easily lead to inconsistency.Larry> On 31 May 2016, at 10:37, Gergely Buday wrote:> > Do I understand correctly that the above remark about adding recursion to a language makes any axiomatisation incomplete is true> > for the same reason that makes it impossible to create a general function definition in a higher order logic of total functions, without the need to supply a termination proof in general?

Hi Manuel.> I just realised that the> following [code_post] rules allow nice printing of natural numbers> (although computation is still done Peano-style behind the curtain):> > > lemma eval_Suc_nat [code_post]:> "Suc 0 = 1"> "Suc 1 = 2"> "Suc (numeral n) = numeral (Num.inc n)"> unfolding One_nat_def numeral_inc by simp_all> > declare Num.inc.simps [code_post]> > > However, for some reason, this does not seem to work for the [simp] and> [nbe] evaluators.What are the failing examples? The following works:value [code] "Suc 42"value [nbe] "Suc 42"value [simp] "Suc 42"> Does anyone apart from me think that something like this should be done?I think the only reason why nobody has ever attempted this so far isthat the old signed numerals did not allow such a simple post processing.Cheers,Florian-- PGP available:http://isabelle.in.tum.de/~haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-----BEGIN PGP SIGNATURE-----Version: GnuPG v2iQIcBAEBCAAGBQJXTztQAAoJEA0EYow68JyZ2a0P/R5SBGlfB6R8v+MZyvafOXQiRIDBqN2YtNVGzS3yJgR7qlNXIAi6RSd0tbfHrgsTxohuddbXdQ/XNcppHcg/O3Uw83eFN6G9PkyZ0+ZEDtwKIIgb68DfS6nI2lVVrzi4DXr/K0IHE6SzMtetcUToV5CrWCL62Ke40GS4dzI6uaUww+Lz/EeHaT3Ke+1/ZPoXaCDrLEMPQPrPvhNNhjGYPaZEZgxoX7l0DeA3g4DFcInKK3sUQuAjzfLhjiEGXYrstoqMT4OOQaZ8sUIHH+2IWriJA4ESo2ZBfk5DDanzkxX0y9okdGlY6zd5Mngcat0X1fX2HOI4cG0KvictJcbCYH3whWrlSocV3PIWooOHwgL043KK75xOG9wYSJlhNJv92JJnCFEk5iERxCeZPqPW7RaNFtuj56KV+tZdcep8wMtf70J/TvD96uSRryh2ptsp8fTvjpOUfTdGuadLUFiZIdHIeVgRL84UgDCaqJcEsNxd7PVRIxrL/eUKJhfj2gG62nyT9NWBgMOUXPLTtRCut/SRdSj9B9Mnt4WK2FkcAqersrgRlu2WqnITsjNkuGzrtTERXzXbLikCtNrET4B2hK2DQYCbEeihvFt/AnXdIzWTa6GvAWaL1kRJwS2c+FiN3nccHPrdJYF7lR2KhFCEa2UXwBt6/WfLixu5UYlGhMCJ=+bTN-----END PGP SIGNATURE-----

> What are the failing examples? The following works:>> value [code] "Suc 42"> value [nbe] "Suc 42"> value [simp] "Suc 42"Odd. I could have sworn this did not work when I tested. But it works now, so even better.> I think the only reason why nobody has ever attempted this so far is> that the old signed numerals did not allow such a simple post processing.Good. Then I suppose I'll add something like this soon. I am also planning to add some code_post rules to print multisets as "{#1,2,3#}" instead of "mset [1,2,3]".

The Algebraic_Numbers theory is notoriously big and resource-intensive. I have a development that imports Algebraic_Numbers and then adds some small things on top of it and exports code. Oddly, this then causes stack overflows unless I switch to 64 bit Isabelle.I noticed that a huge chunk of the resource hunger of that development actually comes from Algebraic_Number_Tests.thy, which one does not even need in order to use the development.I therefore propose removing this theory from the Algebraic_Numbers session and introducing a separate Algebraic_Number_Tests session for it. I tried this locally and this is theh difference that it made:Before: Finished Algebraic_Numbers (0:04:33 elapsed time, 0:15:05 cpu time, factor 3.31)After: Finished Algebraic_Numbers (0:01:18 elapsed time, 0:04:05 cpu time, factor 3.12)Now, I don't know if and by how much this reduces the memory requirements and I have no idea how to measure this reliably. In any case, I do not see any drawbacks of doing this.Any opinions?Cheers,Manuel

> I noticed that a huge chunk of the resource hunger of that development> actually comes from Algebraic_Number_Tests.thy, which one does not even> need in order to use the development.> > Now, I don't know if and by how much this reduces the memory> requirements and I have no idea how to measure this reliably. In any> case, I do not see any drawbacks of doing this.IMHO it is good style that things on which others are supposed to buildupon contain only libraries, not tests. So, I would suggest to go ahead.Cheers,Florian Haftmann-- PGP available:http://isabelle.in.tum.de/~haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-----BEGIN PGP SIGNATURE-----Version: GnuPG v2iQIcBAEBCAAGBQJXT+NJAAoJEA0EYow68JyZt5IP/0m6Zsjf+Zn/0a1yaEYQnMKfsLU+JpEGU2sbE/4wwCGvxdTalTc/79vF/yaEAMKF0T9YB/E1zp0slxx+UkiRTveS5HzXTWGPuDzHSoGI+pPSG31z4028Em+YlOw+hnGBcCG3z6gCDLB/n0IeKdZKZZligWBpzzs8+fGM/R7nh9c7NiMXJ5XVXFgeuRPjINebnRMb7hyhWwssdj+DsyK8LLhL1xGUE35x6Ha9fBQBW3KGM8xcucRvMHz5iVtID1y+Sd1eOuZXw61trOI7nxGmvlf5LXUzHzRdw8L8jkwGToY5rdACexw3uBJRXvRhXnrAfSfoA/dYCLB4qys/6KDyLQT60QMdbEE4kIC4QsN5NARKeLB1QCe+FGjSaOanRk4YzKoYaAuVE6PLmiEjEAHbbE245Mlvx44qM7NrYToX4JLMEvqx3x2lwtOFse7Vj9Lc1kmkpp+I6rTEB/eaza+j7u15YPmy9AzPa4+pSrXs/adkq4exG9dWSTOWXfexdQSDSNogp7X6lahGBcljEtYWFll0rBnupteaVYfYTd8BPjNb8hLq8muYNXb3e2Z63RZQNgGUVtzR3IcVK91K6oaxlA2KED9OV0QtAmp2LIVkRa8818W7US+pxzHD/H453hVsyrTgYCSi+fdaKCJ5Ar/Xc7jdaG8dYGuyPcveR3P6729J=ZV0B-----END PGP SIGNATURE-----

Dear all,it is perfectly fine to me, to create a separate target in the ROOT file without the tests,e.g., as indicated below. However, Im unsure how the document preparation will work in thisway. Somehow both entries contribute to the final PDF, i.e., both parts should be displayed onthe AFP-website.Does anybody know an easy solution to this?Cheers,Rensession Algebraic_Numbers_With_Tests (AFP) = Algebraic_Numbers + description {* Testing Algebraic Number *} options [timeout = 1200] theories "Algebraic_Number_Tests" document_files "root.bib" "root.tex"session Algebraic_Numbers (AFP) = Pre_Algebraic_Numbers + description {* Algebraic Numbers *} options [timeout = 600] theories "Missing_Multiset" "Missing_List" "Compare_Complex" "Improved_Code_Equations" "Precomputation" "Is_Rat_To_Rat" "Ring_Hom_Poly" "Order_Polynomial" "Binary_Exponentiation" "Explicit_Roots" "Rational_Root_Test" "Kronecker_Factorization" "Square_Free_Factorization" "Berlekamp_Hensel_Factorization" "Rational_Factorization" "Real_Factorization" "Show_Real_Approx "Show_Real_Precise" document_files "root.bib" "root.tex"> Am 02.06.2016 um 09:42 schrieb Florian Haftmann :> >> I noticed that a huge chunk of the resource hunger of that development>> actually comes from Algebraic_Number_Tests.thy, which one does not even>> need in order to use the development.>> >> Now, I don't know if and by how much this reduces the memory>> requirements and I have no idea how to measure this reliably. In any>> case, I do not see any drawbacks of doing this.> > IMHO it is good style that things on which others are supposed to build> upon contain only libraries, not tests. So, I would suggest to go ahead.> > Cheers,> Florian Haftmann> > --> > PGP available:> http://isabelle.in.tum.de/~haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de>

-----BEGIN PGP SIGNATURE-----Comment: GPGTools - https://gpgtools.orgiQIcBAEBCgAGBQJXT/0UAAoJEErTVmtC48tJ8t0QAM/t7U6hVA1+pX8Nlif+PoXhj2r8xGoMvCep4sajRhofGTuuFLuo2/bizxIb8DAZf0PU0DDYdsNB4nf1y+wJU3cKnO8ZhPQoAtQUpvUGwWBLxKfX4o5rNCEufc0bvdDoWtGyCVe+jWkAOrW+aSAp0scIe7IZZEFgNLLdf0TmDNBAEry903DP4V2OlFVcTA8w3dT61pycJqxpifUotrhgaN/QOL+zJ7Ft9rEfioGsogj/UXdbNu+e4ooOOB+nNM1b1TWWVRkETc0DtCounCtBYEUJp6Yu6NrWAQbsfu2vi44oCJEUW9jrr++GnQOCFADCnU3Zgw/Pvj6qY4yM2Uh8WD7ZHSmToduaeYDZIBlSRqla/S4iCWjiRwoxULyhwIGk1nj1mjF3cTJQcnc9YmOltR6tSNO6bbl7FZzNhOoEBO1uZYYIeqZr5kxBDil+vB3QwaDfERRgD9aeXeHy2nlmRrpppZ7wLragJXuqIs1lyyjEiwIHhiv5ewX9qFlhmPFDoARUSbR943CsbNOJWbHzBxqU90QIgZqnW2V1WTUOQ9vjINaZAVlk92/DQeHJUhn7J2Wxe80ENHHZ2Z/dIhb7+aSgTIPMDI6JXY4eCbtdcq6/Am0oI9IHEOC4uRUALJkOOYoJDBhcCfVDCHusWWlfsA93ROdMLquE2xbhrIQH98Ps=GsuZ-----END PGP SIGNATURE-----

Dear list,I have problem with using nitpick even for trivial lemma such as: lemma "P Q ".in the output panel, I've got this kodkod warning:Kodkod warning: cannot launch SAT solver, falling back on "DefaultSAT4J"I'm using Isabelle 2016 64-bit windows version. Any suggestion?CheersOmar

Hi Ren,> it is perfectly fine to me, to create a separate target in the ROOT file without the tests,> e.g., as indicated below. However, Im unsure how the document preparation will work in this> way. Somehow both entries contribute to the final PDF, i.e., both parts should be displayed on> the AFP-website.> > Does anybody know an easy solution to this?as far as I can tell, there is no easy solution just yet. Themedium-term goal is to automate publishing of artifacts from stable AFPusing Jenkins. This will mean a publicly-browsable directory of allPDFs, HTMLs, tars, ...CheersLars

The solution is to do it the other way around.Algebraic_Numbers should be the session with everything, generating all documents. Then you add a separate small session without the tests that others can use if they need to conserve resources. This one doesnt even have to produce a document at all.Cheers,Gerwin> On 02.06.2016, at 19:55, Lars Hupel wrote:>> Hi Ren,>>> it is perfectly fine to me, to create a separate target in the ROOT file without the tests,>> e.g., as indicated below. However, Im unsure how the document preparation will work in this>> way. Somehow both entries contribute to the final PDF, i.e., both parts should be displayed on>> the AFP-website.>>>> Does anybody know an easy solution to this?>> as far as I can tell, there is no easy solution just yet. The> medium-term goal is to automate publishing of artifacts from stable AFP> using Jenkins. This will mean a publicly-browsable directory of all> PDFs, HTMLs, tars, ...>> Cheers> Lars>________________________________The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.

AFP entries now have used-by fields, so you can see which other entries use your development.A nice example is http://www.isa-afp.org/entries/Regular-Sets.shtmlCheers,Gerwin________________________________The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.

Dear Omar,> I have problem with using nitpick even for trivial lemma such as: lemma "P> Q ".> in the output panel, I've got this kodkod warning:> Kodkod warning: cannot launch SAT solver, falling back on "DefaultSAT4J"> > I'm using Isabelle 2016 64-bit windows version. Any suggestion?This seems to be a low-level issue. There are hard to debug; let's see if there's a workaround first.In the Nitpick documentation (isabelle doc nitpick), there's a list of SAT solvers that can be tried. You can choose one by setting nitpick_params [sat_solver = ]Could you try e.g. MiniSat as the solver and see if the issue goes away?Cheers,Jasmin

> Thanks for this easy solution. I just pushed a corresponding change> with new target: Algebraic_Number_LibBecause of this we now have the unfortunate situation that a significantpart of Algebraic_Numbers is now being built twice, without any actualneed to do so.CheersLars

Dear Omar,> I have problem with using nitpick even for trivial lemma such as: lemma "P> Q ".> in the output panel, I've got this kodkod warning:> Kodkod warning: cannot launch SAT solver, falling back on "DefaultSAT4J"> > I'm using Isabelle 2016 64-bit windows version. Any suggestion?This seems to be a low-level issue. There are hard to debug; let's see if there's a workaround first.In the Nitpick documentation (isabelle doc nitpick), there's a list of SAT solvers that can be tried. You can choose one by setting nitpick_params [sat_solver = ]Could you try e.g. MiniSat as the solver and see if the issue goes away?Cheers,Jasmin

Dear Omar,First, sorry for the duplicate email. My email client seems to be confused due to all the wifi connections/disconnections.> On 02.06.2016, at 16:23, Omar Jasim wrote:> > I tried this before for the same lemma (lemma "P Q ") and the result was:> [failure]> --------------------> So it seems that just for SAT4J and SAT4J_Light it working correctly but for the rest it not working properly!. SAT4J and SAT4J_Light do not rely on JNI, which is a technology for running binaries, which is always a risky undertaking. I suspect the issue is simply that you are using 64-bit Windows, and for all I know you might be the first user of Nitpick to do so. If you want to debug this further, I suggest we try a debugging session together (e.g. via Skype). Please let me know privately and we can set a time.Cheers,Jasmin

On 02/06/16 20:06, Jasmin Blanchette wrote:>> So it seems that just for SAT4J and SAT4J_Light it working correctly but for the rest it not working properly!. > > SAT4J and SAT4J_Light do not rely on JNI, which is a technology for running binaries, which is always a risky undertaking. I suspect the issue is simply that you are using 64-bit Windows, and for all I know you might be the first user of Nitpick to do so. If you want to debug this further, I suggest we try a debugging session together (e.g. via Skype).The Windows 64 version of Isabelle2016 uses a JDK for x86_64, but thisis also used for OS X and on most Linux installations. It is rare to seex86 JDKs these days, but it can still happen.In contrib/kodkod-1.5.2 (which is used for Isabelle2016), I see thefollowing JNI directories:ppc-darwin/x86-cygwin/x86-darwin/x86-linux/Oddly, x86-darwin and x86-linux contain both x86 and x86_64 binaries,but not x86-cygwin. The presence of ppc-darwin is a hint that thegeneral setup is somewhat outdated.In recent years various Isabelle platform settings have emerged thathelp to sort out this confusion. In particular, ISABELLE_JAVA_PLATFORMsays which Java platform is used for "isabelle java".Makarius

On 02/06/16 11:36, Omar Jasim wrote:> I have problem with using nitpick even for trivial lemma such as: lemma "P> Q ".> in the output panel, I've got this kodkod warning:> Kodkod warning: cannot launch SAT solver, falling back on "DefaultSAT4J"> > I'm using Isabelle 2016 64-bit windows version.Making kodkod work on x86_64-windows is important in its own right.But just for immediate use, you can downgrade to the 32-bit Windowsversion of Isabelle2016 instead.The main difference is the JDK, and its maximum heap resources. 32-bitshould be fine for medium-sized applications.Makarius

On 02/06/16 16:55, Lars Hupel wrote:>> Thanks for this easy solution. I just pushed a corresponding change>> with new target: Algebraic_Number_Lib> > Because of this we now have the unfortunate situation that a significant> part of Algebraic_Numbers is now being built twice, without any actual> need to do so.Indeed. When there are bulky sessions, one should figure out how to makethem less bulky, and not just duplicate bulkiness.Makarius

I thought the point was that the part that is duplicated is *not* bulky. If it is, we should think more, but I dont have any better solutions ready.For comparison, were doing this already: since we cant merge multiple parent sessions, all entries that re-use more than one other entry will currently definitely rebuild all of at least one parent anyway. Given that, and the effort Im spending periodically to make sure the AFP does not rebuild HOL-Library 100 times each day, I dont think the light part of one entry being rebuilt is a problem.Cheers,Gerwin> On 3 Jun 2016, at 1:24 AM, Makarius wrote:>> On 02/06/16 16:55, Lars Hupel wrote:>>> Thanks for this easy solution. I just pushed a corresponding change>>> with new target: Algebraic_Number_Lib>>>> Because of this we now have the unfortunate situation that a significant>> part of Algebraic_Numbers is now being built twice, without any actual>> need to do so.>> Indeed. When there are bulky sessions, one should figure out how to make> them less bulky, and not just duplicate bulkiness.>>> Makarius>>________________________________The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.

On 02/06/16 22:37, Gerwin Klein wrote:> I thought the point was that the part that is duplicated is *not* bulky. If it is, we should think more, but I dont have any better solutions ready.I think the worries of Lars Hupel are based on the rather weakIsabelle/Jenkins testing hardware. My own worries are based on generalobservations that Algebraic_Numbers could be close to the infamous"invisible concrete wall" (without detailed measurements yet).Here are some numbers on the fastest test machine that I have access to(i.e. my own workstation):Isabelle/bcf4828bb125 + AFP/83c0fef83e3fx86-linux, 6 threadsFinished Algebraic_Number_Lib (0:00:48 elapsed time, 0:04:12 cpu time,factor 5.22) ## without heap imageFinished Algebraic_Numbers (0:04:48 elapsed time, 0:22:56 cpu time,factor 4.78) ## based on Pre_Algebraic_NumbersNow the same, but Algebraic_Numbers is based on Algebraic_Number_Lib,i.e. the first session builds a heap and the second only runs the bulkytests:Finished Algebraic_Number_Lib (0:01:17 elapsed time, 0:05:28 cpu time,factor 4.23)Finished Algebraic_Numbers (0:03:54 elapsed time, 0:17:54 cpu time,factor 4.57)This makes some difference in overall CPU time usage. It is reminiscentof ancient times, when Jinja (not JinjaThreads) had to be split into twosessions: the full compactification of the first heap makes the secondone more comfortable. Although the effect today is not that important,due to online heap sharing.There are already AFP entries with more than one session, and alsoadd-on documents. Maybe that is already sufficient to publish the testsseparately, or maybe not. Lars Hupel might be able to say that.Stepping back further, the question is why Algebraic_Number_Testsrequires so much persistent heap memory that sessions built on it mightget into problems. Maybe there is a deeper resource problem behind it.Makarius

On 02/06/16 22:37, Gerwin Klein wrote:> For comparison, were doing this already: since we cant merge multiple parent sessions, all entries that re-use more than one other entry will currently definitely rebuild all of at least one parent anyway. Given that, and the effort Im spending periodically to make sure the AFP does not rebuild HOL-Library 100 times each day, I dont think the light part of one entry being rebuilt is a problem.BTW, for years I am trying to get to a situation where sessions and heapimages are independent (also for document preparation). That would allowto run many AFP sessions within the same Poly/ML process, providing achance that the big number of small sessions uses much less resources.Makarius

> On 3 Jun 2016, at 7:02 AM, Makarius wrote:>> On 02/06/16 22:37, Gerwin Klein wrote:>> For comparison, were doing this already: since we cant merge multiple parent sessions, all entries that re-use more than one other entry will currently definitely rebuild all of at least one parent anyway. Given that, and the effort Im spending periodically to make sure the AFP does not rebuild HOL-Library 100 times each day, I dont think the light part of one entry being rebuilt is a problem.>> BTW, for years I am trying to get to a situation where sessions and heap> images are independent (also for document preparation). That would allow> to run many AFP sessions within the same Poly/ML process, providing a> chance that the big number of small sessions uses much less resources.That would be very useful!Cheers,Gerwin________________________________The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.

> I think the worries of Lars Hupel are based on the rather weak> Isabelle/Jenkins testing hardware. My own worries are based on general> observations that Algebraic_Numbers could be close to the infamous> "invisible concrete wall" (without detailed measurements yet).Better hardware is on its way.> There are already AFP entries with more than one session, and also> add-on documents. Maybe that is already sufficient to publish the tests> separately, or maybe not. Lars Hupel might be able to say that.Presently, all documents for the development version are built, but notpublished. The reason for that is that it turns out the disk spacerequirements to retain all HTML and PDF files is excessive (dozens of GBamassed during two or three weeks). I have a changeset to the buildserver in my pipeline which will retain the latest set of documents.(NB, build logs are retained and will be retained forever; they arerelatively small due to compression.)The remaining question is how these documents will be presented in AFP.Currently only the documents of the main sessions are linked from theentry pages.> Stepping back further, the question is why Algebraic_Number_Tests> requires so much persistent heap memory that sessions built on it might> get into problems. Maybe there is a deeper resource problem behind it.That is an excellent question. I still can't quite put my finger on itas to why that single theory forces us to run AFP tests in bulky 64 bitmode.CheersLars

On 03/06/16 23:17, Lars Hupel wrote:>>> Stepping back further, the question is why Algebraic_Number_Tests>> requires so much persistent heap memory that sessions built on it might>> get into problems. Maybe there is a deeper resource problem behind it.>> That is an excellent question. I still can't quite put my finger on it> as to why that single theory forces us to run AFP tests in bulky 64 bit> mode.I did not know that the situation is that bad.An important point if AFP tests is to see if everything still worksnicely in the small x86 heap model. That is one aspect of the "invisibleconcrete wall".Makarius

> Presently, all documents for the development version are built, but not> published. The reason for that is that it turns out the disk space> requirements to retain all HTML and PDF files is excessive (dozens of GB> amassed during two or three weeks). I have a changeset to the build> server in my pipeline which will retain the latest set of documents.That is a good idea, I dont think we need to keep all artefacts.> (NB, build logs are retained and will be retained forever; they are> relatively small due to compression.)Good, these are worth keeping, at least for a moderately longer time span. They enable statistics etc.> The remaining question is how these documents will be presented in AFP.> Currently only the documents of the main sessions are linked from the> entry pages.Extra sessions and documents should be very rare, i.e. almost all AFP sessions should have exactly one document, which is the one that is linked.Is this not the case or am I misunderstanding the question?>> Stepping back further, the question is why Algebraic_Number_Tests>> requires so much persistent heap memory that sessions built on it might>> get into problems. Maybe there is a deeper resource problem behind it.>> That is an excellent question. I still can't quite put my finger on it> as to why that single theory forces us to run AFP tests in bulky 64 bit> mode.Does sound worth investigating, I have no direct ideas either.Maybe it is indeed time to officially enable multiple sessions for AFP entries. That will take some infrastructure work, but it would give us more flexibility in treating things like this, for instance with the technique Makarius mentioned, which we used for Jinja years back.Cheers,Gerwin________________________________The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.

On 04/06/16 02:34, Gerwin Klein wrote:> >>> Stepping back further, the question is why Algebraic_Number_Tests>>> requires so much persistent heap memory that sessions built on it might>>> get into problems. Maybe there is a deeper resource problem behind it.>>>> That is an excellent question. I still can't quite put my finger on it>> as to why that single theory forces us to run AFP tests in bulky 64 bit>> mode.> > Does sound worth investigating, I have no direct ideas either.> > Maybe it is indeed time to officially enable multiple sessions for AFP entries. That will take some infrastructure work, but it would give us more flexibility in treating things like this, for instance with the technique Makarius mentioned, which we used for Jinja years back.The split into two sessions had mainly the effect to enforce a full heapcompaction (and reload). In contempory Poly/ML this can be done atruntime, e.g. by putting this into a suitable place (e.g.Algebraic_Number_Tests.thy):ML_command %invisible \ML_Heap.share_common_data ()\Here are some measurements for Isabelle/d8884c111bca + AFP/44c49a721891on x86-linux with 6 threads.(0) standard setup:Finished Algebraic_Numbers (0:04:21 elapsed time, 0:20:03 cpu time,factor 4.60)(1) ML_command share_common_data:Finished Algebraic_Numbers (0:05:23 elapsed time, 0:23:52 cpu time,factor 4.43)(2) Algebraic_Numbers based on Algebraic_Number_Lib:Finished Algebraic_Number_Lib (0:01:18 elapsed time, 0:05:31 cpu time,factor 4.21)Finished Algebraic_Numbers (0:04:07 elapsed time, 0:17:55 cpu time,factor 4.34)The times for (1) are approximately equal to the sums of times for (2).Maybe Lars can try share_common_data on the AFP test hardware to see ifit still happens to work on 32bit architecture.Makarius

Hello,is there any alternative way of writing{5n.nN} other than {k. \ex n. k = 5n}..such as using with "forAll" operator or so (thus avoiding the existence-quantor?)Thank you!

Hi Jonathan,> is there any alternative way of writing {5n.nN} other than {k. \ex > n. k = 5n}..such as using with "forAll" operator or so (thus avoiding> the existence-quantor?)try this: {5 * n | n. n }CheersLars

{n. n `mod` 5 = 0}On 06/06/16 13:04, Jonathan Woodgate via Cl-isabelle-users wrote:> Hello,> is there any alternative way of writing {5n.nN} other than {k. \ex n. k = 5n}..such as using with "forAll" operator or so (thus avoiding the existence-quantor?)> Thank you!>

Yes, that is the ideal (5), which is the smallest ideal containing 5. Idon't know the Isabelle notation, but that would be something like{n. forall i in Ideals(N), 5 in i => n in i}where i in Ideals(N) if ax+b in i whenever a,b in i and x in N.MarioOn Mon, Jun 6, 2016 at 7:04 AM, Jonathan Woodgate via Cl-isabelle-users wrote:> Hello,> is there any alternative way of writing {5n.nN} other than {k. \ex n. k => 5n}..such as using with "forAll" operator or so (thus avoiding the> existence-quantor?)> Thank you!>>

Thank you! Mario Carneiro schrieb am 13:20 Montag, 6.Juni 2016: Yes, that is the ideal (5), which is the smallest ideal containing 5. Idon't know the Isabelle notation, but that would be something like{n. forall i in Ideals(N), 5 in i => n in i}where i in Ideals(N) if ax+b in i whenever a,b in i and x in N.MarioOn Mon, Jun 6, 2016 at 7:04 AM, Jonathan Woodgate via Cl-isabelle-users wrote:> Hello,> is there any alternative way of writing {5n.nN} other than {k. \ex n. k => 5n}..such as using with "forAll" operator or so (thus avoiding the> existence-quantor?)> Thank you!>>

Thanx! Lars Hupel schrieb am 13:12 Montag, 6.Juni 2016: Hi Jonathan,> is there any alternative way of writing {5n.nN} other than {k. \ex > n. k = 5n}..such as using with "forAll" operator or so (thus avoiding> the existence-quantor?)try this: {5 * n | n. n }CheersLars

Dear list,Is there an equivalent to turnstile in Isabelle? In good oldmathematics and in other HOL systems, the turnstile (|-) has two roles:to indicate that a theorem has been proved, and to separate anyassumptions of the theorem from its conclusion.In Isabelle2005, if you return a theorem in the read-eval-print-loop,then if it has one assumption 'P' and conclusion 'Q' then it getsprinted as "Q [P]" (if the flag for showing hypotheses is set), but justas "Q" if there are no assumptions, and so this corresponds to thesecond role.But what about in more recent Isabelles? I know that there's noread-eval-print-loop as such, and that in Isar scripts you write"theorem" before a formula, which is a bit like the first role but notquite because until the proof is complete it states the intention thatthe formula will be proved rather than that it has been proved. Arethere ways of displaying lists of theorems, and if so how are thesepresented? I note that the printer for "Q [P]" is still there in theIsabelle Pure source. If anyone could shed any light on all of thisthen I'd be most grateful.Mark.

On Di, 2016-06-07 at 00:51 +0100, Mark Adams wrote:> Dear list,> > Is there an equivalent to turnstile in Isabelle? In good old> mathematics and in other HOL systems, the turnstile (|-) has two roles:> to indicate that a theorem has been proved, and to separate any> assumptions of the theorem from its conclusion.> > In Isabelle2005, if you return a theorem in the read-eval-print-loop,> then if it has one assumption 'P' and conclusion 'Q' then it gets> printed as "Q [P]" (if the flag for showing hypotheses is set), but just> as "Q" if there are no assumptions, and so this corresponds to the> second role.> > But what about in more recent Isabelles? I know that there's no> read-eval-print-loop as such, and that in Isar scripts you write> "theorem" before a formula, which is a bit like the first role but not> quite because until the proof is complete it states the intention that> the formula will be proved rather than that it has been proved. Are> there ways of displaying lists of theorems, and if so how are these> presented? I note that the printer for "Q [P]" is still there in the> Isabelle Pure source. If anyone could shed any light on all of this> then I'd be most grateful.The hypothesis are used in Isabelle merely internally, and thestandard-user should not see them. Theorems are presented asmeta-implications "P1==>...==>Pn==>Q", or, syntax-sugared "[| P1;...;Pn|] ==> Q". This is also the way they are printed. In Isar, you can use the "thm" command to print (a list of) theorems.To state a theorem, you can either use meta-implications, or the"long-goal" format:lemma foo: assumes P1 and ... and Pn shows QBy the very design of Isabelle, every theorem has been proved (or has apending future proof attached [Makarius, correct me if I'm wronghere ;)])-- Peter> > Mark.

Im presently looking (with Simon Thompson) for two Post Docs to work on a CakeML related project. (Although the CakeML verified compiler is developed in HOL4, rather than Isabelle, it is the same kind of verification project that is very common in the Isabelle world too.) The posts last for 3.5 years and are at the University of Kent in Canterbury, England. Applications are due by *12 June, 2016*.Here is a brief description of the project:Trustworthy Refactoring project: Research Associate Positions in Refactoring Functional Programs and Formal Verification (for CakeML) The Trustworthy Refactoring project at the University of Kent is seeking to recruit postdoc research associates for two 3.5 year positions, to start in September this year.The overall goal of this project is to make a step change in the practice of refactoring by designing and constructing of trustworthy refactoring tools. By this we mean that when refactorings are performed, the tools will provide strong evidence that the refactoring has not changed the behaviour of the code, built on a solid theoretical understanding of the semantics of the language. Our approach will provide different levels of assurance from the (strongest) case of a fully formal proof that a refactoring can be trusted to work on all programs, given some pre-conditions, to other, more generally applicable guarantees, that a refactoring applied to a particular program does not change the behaviour of that program. The project will make both theoretical and practical advances. We will build a fully-verified refactoring tool for a relatively simple, but full featured programming language (CakeML https://cakeml.org), and at the other we will build an industrial-strength refactoring tool for a related industrially-relevant language (OCaml). This OCaml tool will allow us to explore a range of verification techniques, both fully and partially automated, and will set a new benchmark for building refactoring tools for programming languages in general. The project, which is coordinated by Prof Simon Thompson and Dr Scott Owens, will support two research associates, and the four will work as a team. One post will focus on pushing the boundaries of trustworthy refactoring via mechanised proof for refactorings in CakeML, and the other post will concentrate on building an industrial strength refactoring tool for OCaml. The project has industrial support from Jane Street Capital, who will contribute not only ideas to the project but also host the second RA for a period working in their London office, understanding the OCaml infrastructure and their refactoring requirements.You are encouraged to contact either of the project investigators by email (s.a.owens@kent.ac.uk, s.j.thompson@kent.ac.uk) if you have any further questions about the post, or if you would like a copy of the full research application for the project. We expect that applicants will have PhD degree in computer science (or a related discipline) or be close to completing one. For both posts we expect that applicants will have experience of writing functional programs, and for the verification post we also expect experience of developing (informal) proofs in a mathematical or programming context.To apply, please go to the following web pages:Research Associate in Formal Verification for CakeML (STM0682): https://jobs.kent.ac.uk/fe/tpl_kent01.asp?s=4A515F4E5A565B1A&jobid=40106,3472764668&key=47167934&c=549534472123&pagestamp=sejmwzlocjpwfyyfakResearch Associate in Refactoring Functional Programs (STM0683): https://jobs.kent.ac.uk/fe/tpl_kent01.asp?s=4A515F4E5A565B1A&jobid=40107,6987525698&key=47167934&c=549534472123&pagestamp=sesioeandjktfucacsSimon and Scott

Hello,I'm working on a verification of properties of a large set containingapproximately 2 million objects. Each object is relatively simple.These objects were constructed by a computer program; now I want to provethat the result of the program is correct.My plan is 1. to define 2 million objects. 2. to prove properties of every object (that is I need 2 million lemmas).Each lemma has But what about in more recent Isabelles? I know that there's no> read-eval-print-loop as such, and that in Isar scriptsIsar is about structured proof *documents* or proof *texts*, not"scripts". It is important to use the proper terminology to get someidea how things work.Isabelle is a document-oriented proof composition tool, with timelessand stateless continuous checking.> "theorem" before a formula, which is a bit like the first role but not> quite because until the proof is complete it states the intention that> the formula will be proved rather than that it has been proved.The 'theorem' command is more than an old-fashioned "goal" statement. Itbuilds up a context and states conclusions from that context: the resultis a Pure rule.This is ubiquitious in the Isabelle/Isar documentation, e.g. "isar-ref"or "implementation" manual.> Are there ways of displaying lists of theorems, and if so how are these> presented? I note that the printer for "Q [P]" is still there in the> Isabelle Pure source. If anyone could shed any light on all of this> then I'd be most grateful.Here is an example for current Isabelle2016:theorem test: fixes x y z :: 'a assumes "x = y" and "y = z" shows "x = z" and "z = x" using assms by simp_allML val thms = @{thms test}; map (fn thm => (Thm.hyps_of thm, Thm.prop_of thm)) thms;The hyps are empty, because the result lives in a global context.Here is an example with a local context:context fixes x y z :: 'a assumes asms: "x = y" "y = z"begintheorem test': "x = z" and "z = x" using asms by simp_allML val thms = @{thms test'}; map (fn thm => (Thm.hyps_of thm, Thm.prop_of thm)) thms;endML val thms = @{thms test'}; map (fn thm => (Thm.hyps_of thm, Thm.prop_of thm)) thms;Hyps are potentially non-empty in the local context, and empty outsideof it. Note that hyps record aspects of the proof in the thm object.This is also the reason why in recent years, hyps are hardly everprinted: this would lead to non-determinism, depending on the theaccidental state of a future proof process that might fail or finishonly later.Makarius

On 07/06/16 08:53, Peter Lammich wrote:> > By the very design of Isabelle, every theorem has been proved (or has a> pending future proof attached [Makarius, correct me if I'm wrong> here ;)])A thm value is indeed only a promise to finish a proof eventually. Forfully authentic results, one needs to do a batch run with "isabellebuild", which forms a global join on all open ends in the very end, andpotential errors are exposed.This reform of thm-ness goes back to 2007/2008, when parallel proofconstruction in Isabelle emerged for the first time.Makarius

Dear Stanislav,I had a similar problem when checking some objects that came out of the Kepler conjecture proof where I had 5 definitions of lists of (in total) 20.000 graphs. Isabelle choked on those when inputting them as an HOL definition. This is what I did instead:1. I first defined those lists in ML files so they could be read by by the PolyML parser. Then I used some magic to import those ML definitions as HOL definitions. Here is the magic code:http://www.isa-afp.org/browser_info/current/AFP/Flyspeck-Tame/Arch.htmlCode_Runtime.polyml_as_definition performs that conversion. You would need to adapt this to your own situation. It worked because the types used on the ML existed on the HOL level: integers and lists.2. To reduce the time to check the objects I wrote the checker in the executable subset of HOL. The final theoremshttp://www.isa-afp.org/browser_info/current/AFP/Flyspeck-Tame/ArchComp.htmlwere proved with "eval", a proof method that compiles executable theorems to ML and runs them there, i.e. reduces them to true or false. (The fact that the definitions were initially made in ML is orthogonal to the final proof by ML.)BestTobiasOn 06/06/2016 20:44, wrote:> Hello,>> I'm working on a verification of properties of a large set containing> approximately 2 million objects. Each object is relatively simple.> These objects were constructed by a computer program; now I want to prove> that the result of the program is correct.> My plan is> 1. to define 2 million objects.> 2. to prove properties of every object (that is I need 2 million lemmas).> Each lemma has approx. 500*2mln = 1billion simple steps.> I'm going to generate the proofs for all that lemmas by another computer> programs.>> Has anybody worked with specifications of this size?> Is it practical to conduct a proof of this size in Isabelle/HOL? If yes,> can you recommend how to organize the proof? If no, can you suggest other> verification tools?>> My experiments show that it is impractical to define a set of 2 million> objects in Isabelle/HOL (Isabelle allocates a lot of memory and the> computation time is large).> I found that many small-size definitions are easier to handle than one> large definition. E.g. I was able to define 20 000 sets a1,...,a20000> containing 100 elements and then define 200 sets b1,...,b200 (each being a> union of 100 sets a_{100*i+1},...,a_{100*i+200}), and finally define a set> C as a union of b1,...,b200. But for aesthetic reasons I don't like it.> Moreover, given the speed of Isabelle, I'm not sure that proofs of 2> million lemmas can be conducted in a reasonable time (say, less than two> months).>> Any ideas?>> Stanislav.>

On 06/06/16 20:44, ? ? wrote:> I'm working on a verification of properties of a large set containing> approximately 2 million objects. Each object is relatively simple.> These objects were constructed by a computer program; now I want to prove> that the result of the program is correct.> My plan is> 1. to define 2 million objects.> 2. to prove properties of every object (that is I need 2 million lemmas).> Each lemma has approx. 500*2mln = 1billion simple steps.> I'm going to generate the proofs for all that lemmas by another computer> programs.These numbers are not that big, but if you go through surface syntax ofIsabelle (the logical language, the theory and proof language, maybeeven just ML source language) it is likely to choke.Note that the canonical way to import big things into an LCF-styleprover like Isabelle is to write some ML functions that do that, andconstruct terms and proofs by internal means. Never ever generate sourcethat is then fed into the system.Examples for reading external material can be seen in src/HOL/SPARK.In such applications it is important to recall that surface syntax (forinput and output of end-user material) is really just the surface andnot the real system. E.g. the SPARK importer turned out incredible slow,until someone pointed out that there is redundant output of intermediatestatements.Makarius

Hallo,I've been playing around with normalisation of monad expressions and have run into a few problems.First of all, one thing I noticed is that the simplifier sometimes fails to apply permutative rules when I thought it should, e.g. minimal example:typedecl atypedecl btypedecl ctypedecl daxiomatization a :: "(a a c) d" and b :: "b b c" and c :: "a a b" where a_commute: "a (x y. b (f x y) (g x y)) a (x y. b (g x y) (f x y))"ML_val let val ctxt = @{context} addsimps @{thms a_commute} val ct = @{cterm "a (x y. b (c x y) (c y x))"} val ct' = @{cterm "a (y x. b (c x y) (c y x))"} in (ct,ct') |> apply2 (Raw_Simplifier.rewrite_cterm (false,false,false) (K (K NONE)) ctxt) endI would have expected the simplifier to rewrite one of these terms to the other but it doesn't do anything for either of them. After adding some tracing code, I believe that the reason is that the simplifier does not -normalise terms before comparing them. Is this the intended behaviour?In any case, for monad normalisation, the simplifier's idea of what constitutes a permutative rule is too restrictive in any case, so I set up a "TERM_ORD" dummy constant similar to the "NO_MATCH" and "ASSUMPTION" constants. "TERM_ORD a b" gets rewritten to "True" by a simproc iff the first argument is strictly smaller than the second. (cong rules ensure that TERM_ORD's arguments do not get simplified themselves) For the reasons outlined above, it also performs --reduction before comparing the terms.This works very well in most cases, but I found one pathological example of the formt := bind A (x. bind A (y. bind (B x y) (_. bind (B y x) (_. e))))The commutativity rule for bind, which isbind A (x. bind B (y. C x y)) = bind B (y. bind A (x. C x y)) ,can be applied either to the whole of t (flipping the first two binds) or to the third bind (flipping the 3rd and 4th bind). In both cases, we get the termt' := bind A (x. bind A (y. bind (B y x) (_. bind (B x y) (_. e))))The problem is now that when flipping the first two binds, the arguments of B are "Bound 1" and "Bound 0". However, when flipping the last two binds, they are "Free ":001"" and "Free ":002"" because the simplifier instantiates bound variables to free variables like this when passing an abstraction. This exactly reverses the term order, since the Bounds are counted inside-out and the Frees are counted outside-in. This means that "TERM_ORD" will be rewritten to "True" in both cases and we get an infinite rewriting cycle.What is the best way to solve this problem? Can the simplifier ever run into a problem like this or is that prevented by the fact that it doesn't do normalisation?The most robust way would probably be to replace the Free variables with (dangling) bound variables before performing the term order comparison, but I don't think the necessary information is publicly available in the context.Cheers,Manuel

Dear all,For some reason i can not execute more than 1 Jedit process on Windows.Is it a problem with the Jedit version comming with Isabelle-2016?Is there any option that i should modify?Is it a jedit options problem? or for some reasons we can't execute morethan 1 Isabelle-2016 processes on Windows?When i try to execute Isabelle-2016 twice, Windows print the followingerror: "Windows can not access to the specified file. You don't havethe permissionsto access this element."PS: the error is a translation from the french version of the message.Best,Yakoub.

On 07/06/16 23:27, Nemouchi Yakoub wrote:> > When i try to execute Isabelle-2016 twice, Windows print the following> error:> > "Windows can not access to the specified file. You don't have> the permissions> to access this element."In principle, Isabelle2016.exe should be a single-instance desktopapplication: when you open it again, it merely reactivates the alreadyopen program as usual. Of course, there can be always technical problemsto prevent this.* What exactly is your Windows version?* What happens when you start Isabelle2016.exe first, and after waitinga bit, run "isabelle jedit_client" in the Cygwin-Terminal?With "isabelle jedit" on the command line, it should be possible to runseveral jEdit processes, but they can still get into problems whenproperties are changed (one or the other version might get lost).Makarius

On 08/06/2016 15:01, wrote:> Dear Tobias and Makarius!> Thank you for your links and suggestions.>> Now I realize that it's better to import my objects to ML directly. I will> concentrate on this approach.>> I have a question regarding "eval" proof method.> If one uses "eval", what stack of code will one have to trust? Will the "trusted> base" be larger than that for proofs without "eval"?Yes, you also need to trust the translation of HOL function definitions into ML function definitions.Tobias> If you can give any links discussing the topic of trusted code stack in theorem> provers (whether in case of "eval" method or not) I would appreciate it.>> Thank you!> Stanislav.>

> * What exactly is your Windows version?> I am using Windows 7 64-bits.> * What happens when you start Isabelle2016.exe first, and after waiting> a bit, run "isabelle jedit_client" in the Cygwin-Terminal?It works fine, with Cygwin i can run multiple processes even if iexecuted Isabelle2016.exebefore.> With "isabelle jedit" on the command line, it should be possible to run> several jEdit processesYes it is correct and it works fine.Thank you for the help.2016-06-08 14:40 GMT+02:00 Makarius :> On 07/06/16 23:27, Nemouchi Yakoub wrote:> >> > When i try to execute Isabelle-2016 twice, Windows print the following> > error:> >> > "Windows can not access to the specified file. You don't have> > the permissions> > to access this element.">> In principle, Isabelle2016.exe should be a single-instance desktop> application: when you open it again, it merely reactivates the already> open program as usual. Of course, there can be always technical problems> to prevent this.>> * What exactly is your Windows version?>> * What happens when you start Isabelle2016.exe first, and after waiting> a bit, run "isabelle jedit_client" in the Cygwin-Terminal?>>> With "isabelle jedit" on the command line, it should be possible to run> several jEdit processes, but they can still get into problems when> properties are changed (one or the other version might get lost).>>> Makarius>>>>>>

Emm..What i can do is s creen shot of the different instances and the list ofthe running processes if you need it to investigate the problem.Best,Yakoub.2016-06-08 22:53 GMT+02:00 Makarius :> On 08/06/16 22:16, Nemouchi Yakoub wrote:> >> * What exactly is your Windows version?> >> I am using Windows 7 64-bits.> >> >> * What happens when you start Isabelle2016.exe first, and after waiting> >> a bit, run "isabelle jedit_client" in the Cygwin-Terminal?> >> > It works fine, with Cygwin i can run multiple processes even if i> > executed Isabelle2016.exe before.>> But this means something does not work properly: after starting the> Isabelle2016.exe application, any "isabelle jedit_client" invocations> should connect to that single instance.>>> Makarius>>>

The fact that the simplifier does not -normalise terms before comparing them is possibly a combination of the fact that I never expected it to be used in such situations and the potential cost of the normalisation. I suspect it would break too many proofs if we changed that behaviour, although I would of course make sense from a logical point of view.TobiasOn 08/06/2016 08:38, Manuel Eberl wrote:> Hallo,>> I've been playing around with normalisation of monad expressions and have run> into a few problems.>> First of all, one thing I noticed is that the simplifier sometimes fails to> apply permutative rules when I thought it should, e.g. minimal example:>>> typedecl a> typedecl b> typedecl c> typedecl d>> axiomatization> a :: "(a a c) d" and> b :: "b b c" and> c :: "a a b"> where> a_commute: "a (x y. b (f x y) (g x y)) a (x y. b (g x y) (f x y))">> ML_val > let> val ctxt = @{context} addsimps @{thms a_commute}> val ct = @{cterm "a (x y. b (c x y) (c y x))"}> val ct' = @{cterm "a (y x. b (c x y) (c y x))"}> in> (ct,ct') |> apply2 (Raw_Simplifier.rewrite_cterm (false,false,false) (K (K> NONE)) ctxt)> end> >>> I would have expected the simplifier to rewrite one of these terms to the other> but it doesn't do anything for either of them. After adding some tracing code,> I believe that the reason is that the simplifier does not -normalise terms> before comparing them. Is this the intended behaviour?>>> In any case, for monad normalisation, the simplifier's idea of what constitutes> a permutative rule is too restrictive in any case, so I set up a "TERM_ORD"> dummy constant similar to the "NO_MATCH" and "ASSUMPTION" constants. "TERM_ORD a> b" gets rewritten to "True" by a simproc iff the first argument is strictly> smaller than the second. (cong rules ensure that TERM_ORD's arguments do not get> simplified themselves) For the reasons outlined above, it also performs> --reduction before comparing the terms.>> This works very well in most cases, but I found one pathological example of the> form>> t := bind A (x. bind A (y. bind (B x y) (_. bind (B y x) (_. e))))>> The commutativity rule for bind, which is>> bind A (x. bind B (y. C x y)) = bind B (y. bind A (x. C x y)) ,>> can be applied either to the whole of t (flipping the first two binds) or to the> third bind (flipping the 3rd and 4th bind). In both cases, we get the term>> t' := bind A (x. bind A (y. bind (B y x) (_. bind (B x y) (_. e))))>> The problem is now that when flipping the first two binds, the arguments of B> are "Bound 1" and "Bound 0". However, when flipping the last two binds, they are> "Free ":001"" and "Free ":002"" because the simplifier instantiates bound> variables to free variables like this when passing an abstraction. This exactly> reverses the term order, since the Bounds are counted inside-out and the Frees> are counted outside-in. This means that "TERM_ORD" will be rewritten to "True"> in both cases and we get an infinite rewriting cycle.>> What is the best way to solve this problem? Can the simplifier ever run into a> problem like this or is that prevented by the fact that it doesn't do > normalisation?>> The most robust way would probably be to replace the Free variables with> (dangling) bound variables before performing the term order comparison, but I> don't think the necessary information is publicly available in the context.>>> Cheers,>> Manuel>>>>>>

Dear Tobias and Makarius!Thank you for your links and suggestions.Now I realize that it's better to import my objects to ML directly. I willconcentrate on this approach.I have a question regarding "eval" proof method.If one uses "eval", what stack of code will one have to trust? Will the"trusted base" be larger than that for proofs without "eval"?If you can give any links discussing the topic of trusted code stack intheorem provers (whether in case of "eval" method or not) I wouldappreciate it.Thank you!Stanislav.

Finite Machine Word LibraryJoel Beeren, Matthew Fernandez, Xin Gao, Gerwin Klein, Rafal Kolanski, Japheth Lim, Corey Lewis, Daniel Matichuk and Thomas SewellThis entry contains an extension to the Isabelle library for fixed-width machine words. In particular, the entry adds quickcheck setup for words, printing as hexadecimals, additional operations, reasoning about alignment, signed words, enumerations of words, normalisation of word numerals, and an extensive library of properties about generic fixed-width words, as well as an instantiation of many of these to the commonly used 32 and 64-bit bases.http://www.isa-afp.org/entries/Word_Lib.shtmlEnjoy!

Dear Lifting experts,I am looking for some documentation on how the Lifting tool derives the parametrised transfer rules from the parametricity theorem. In some cases, lift_definition reports that it was not able to merge certain terms. I'd like to understand how this works and its limitations. I have a different application in mind (strengthening parametricity theorems with congruence rules) and would like to understand whether the same approach could work there.Best,Andreas

Hi,Is there a way to make the SML code generator use opaque ascription "structure Foo :> FOO = struct ... end" rather than transparent ascription "structure Foo : FOO = struct ... end"?OCaml does not have transparent ascription so perhaps the default for SML should be opaque ascription.Thanks,Jrgen

Hi Jrgen,> Hi,> > Is there a way to make the SML code generator use opaque ascription "structure Foo :> FOO = struct ... end" rather than transparent ascription "structure Foo : FOO = struct ... end"?the short answer is, no.> OCaml does not have transparent ascription so perhaps the default for SML should be opaque ascription.The Isabelle/ML tradition prevers abstypes over opaque ascriptions asfar as I remember also pretty printing of values work better withabstypes than opaque ascriptions. When signatures have been added toSML code generation, this pattern has been adopted. Maybe it is time torevisit that.Cheers,Florian-- PGP available:http://isabelle.in.tum.de/~haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-----BEGIN PGP SIGNATURE-----Version: GnuPG v2iQIcBAEBCAAGBQJXXV0lAAoJEA0EYow68JyZHXYP/jdJpeYY+vwiceIOtksUo12tV2QZvTypetiZRn8O8s1VDeXGkFOoqP4OETN+ei9ZPtlf2aPIa6HetB2wr9EfP5sn3CGXub2BM0zgPzgV3mKPyB1CWOoC1aaRr0rZzDkSN9NF8gt0tDjZQbNXCteHrkir44BBzUKCMR8ZVZR/ZgvY11X+wI9H6sruvHh3WRk4xvztX5DLE2nR26IRBSRStmhXaBTx0Spm07KEPa6BiMyoUeiLqFhanfEt62iukXjQrLIz0Z8mo3iJubZmxamFARkVVn4ROatE20vdj37Ipia/RnrRzYJLUEWQlZ4syGOIbVz4jpRrA/Uev83068bUDyDSisr6+quYebkmxzIclFYOwxp1MzXiX5K7z+AB+2crwz01WRKmPVnzmQMzC4w/2/Vz2vpVCAfNYTdRh3O2AadNDY3vPJ4/PlH7oAT0DKbdjc0DqXizYlDPsUtpe2XDPtrCFPfCo5SIokdtKQRcaQqD+k/y/dSIg5d0DmpjkQkq3VZZhU4K9rO0xhoXmSdqLvXWljErRqExAVwJ6PrYjo3Zp3zafhV0f8NAF+lQMsAXd3Oh7Cc9NGwC3Wc01EKzXrxuTN/c7aavV4pqbNa4Oaaxm8fIgmLAhbKxlry5hNbRd2m/8qWPu6u+RT3bzjRSAO383woAZ9b/cmqjRcnR15cZ=o05X-----END PGP SIGNATURE-----

On 12/06/16 15:01, Florian Haftmann wrote:>> Is there a way to make the SML code generator use opaque ascription "structure Foo :> FOO = struct ... end" rather than transparent ascription "structure Foo : FOO = struct ... end"?> > the short answer is, no.> >> OCaml does not have transparent ascription so perhaps the default for SML should be opaque ascription.> > The Isabelle/ML tradition prevers abstypes over opaque ascriptions as> far as I remember also pretty printing of values work better with> abstypes than opaque ascriptions. When signatures have been added to> SML code generation, this pattern has been adopted. Maybe it is time to> revisit that.See alsohttp://stackoverflow.com/questions/7296795/sml-whats-the-difference-between-using-abstype-and-using-a-signature-to-hide-tAfter the Isabelle2016 release, we have discontinued SML/NJ and oldversions of Poly/ML, so there is a bit more flexibility now in canonicalpatterns for Isabelle/ML.The example with structure A3 from above is the difficult one, notablythe situation "does not work (overrides pp for int)". Defining the ppoutside of the structure basically works, but exceptions are not printedcorrectly. This is how the problem with opaque ascription was discoveredmany years ago, and the abstype solution took over.Here is an update of the example A3 from Stackoverflow above, usingIsabelle2016 with its bundled Poly/ML 5.6:ML structure A :>sig type t exception BAD of t datatype test = Test of t val a: t val print: t -> stringend =structtype t = intexception BAD of tdatatype test = Test of tval a = 42fun print i = "{" ^ Int.toString i ^ "}"(*1*)(*val _ = PolyML.addPrettyPrinter (fn _ => fn _ => fn x =>PolyML.PrettyString (print x))*)end;(*2*)(*val _ = PolyML.addPrettyPrinter (fn _ => fn _ => fn x =>PolyML.PrettyString (A.print x))*)ML A.a; A.Test A.a; A.BAD A.aThis leads to a mix of results, depending on the place where the prettyprinter is installed.I still don't see how to get a simple and robust pretty printer setup,so we can't use opaque ascription unless David Matthews wants torefine that again for a future release of Poly/ML.Makarius

-----BEGIN PGP SIGNATURE-----Version: GnuPG v2iQIcBAEBCAAGBQJXXXAkAAoJEPPSlBKBv024JtIP/3PCbxTSM6+BlEa0Pr9je8HZ3t1mtmSVluSVTBHweTBzaq9dJqTGOprNolp0AzzwD5oU8QjdD9HA/PmSkDQabd9UWZyraa4uySv5deZj23fVrzGCiCOeorKObWk/VjHx8Ko6Lh8JtXrHFYpfZi4+T+duwSyDhdyiDHoFme35HrUn4D6V990aLY/bf5ny5aR+SapPJGyM0Q77RKVzHz12zy/OcNgDsrzZ86mfDMCto7DlAdfMwa/WdOBsk/A3dVpRNoTV6u9FksdyBl9jUvpoKkBiyHIuYvNIvof5Z4ASfEKbTiq/3I+6M1d4yC/42N5Jr5JXhOLy83AvMBZSh3R/yx7Kc1w/ieuYMbK3yUvNebGAvS5UaPaW3dQz9+jZm55FxaO37JySVBQgpr1fx7aU0L3XY8HtF9gpQ3u9IQJew4te3KRC2rSDgxQURyr8Q4Ycy4WOmFdWilrXGV4R2fOyXMGcf0bfVtpjb43aJlLf94m/X8z8MXBLA0rvwKavpm+YFHB4cR2ieFMrDaL1pubnYM57XzT6ujJNLpNkep5VplliGucO6ztYPSJb/ykC1tdSqdda2hWOUJrdvLpMt5dn8t/9tRwgvjEQrkXwq81jA27PKHmCa9bF9ug6G6BgBSAeqYFmWWeFf1wAIeOpYOcjl/a50NNKEkjAs4+m+QhZVL4W=rBiA-----END PGP SIGNATURE-----

Pretty-printing isn't part of the ML standard so it's not always clear how to do it properly. There have been various changes over the years. In particular, printing exception packets is difficult because the packet can contain values of types that exist only where the exception is raised. In the example below, "t" may not actually be exported from the signature. So, Poly/ML puts the print function that applies where the exception is raised into the exception packet and uses that if it needs to print the packet. There are no plans to change this.There have been some changes around the printing of types exported through opaque matching. When a structure matches a signature containing a type through opaque matching the semantics says that this creates a new type "name". Poly/ML creates a new ref to hold the pretty print function for the new type. Previously this was initialised to the pretty print function for the implementing type but this was changed in 5.6.1 to default to printing "?". It later became clear that this was too restrictive when the signature contained a datatype (e.g. "test" below) so there was a further change in commit 29985b1c in git master. So now if you install pretty printers both within the structure, (*1*) below, for the exception, and outside the signature (*2*) it will work as you expect.DavidOn 12/06/2016 15:22, Makarius wrote:> After the Isabelle2016 release, we have discontinued SML/NJ and old> versions of Poly/ML, so there is a bit more flexibility now in canonical> patterns for Isabelle/ML.>> The example with structure A3 from above is the difficult one, notably> the situation "does not work (overrides pp for int)". Defining the pp> outside of the structure basically works, but exceptions are not printed> correctly. This is how the problem with opaque ascription was discovered> many years ago, and the abstype solution took over.>>> Here is an update of the example A3 from Stackoverflow above, using> Isabelle2016 with its bundled Poly/ML 5.6:>> ML > structure A :>> sig> type t> exception BAD of t> datatype test = Test of t> val a: t> val print: t -> string> end => struct>> type t = int>> exception BAD of t> datatype test = Test of t>> val a = 42>> fun print i = "{" ^ Int.toString i ^ "}">> (*1*)> (*val _ = PolyML.addPrettyPrinter (fn _ => fn _ => fn x =>> PolyML.PrettyString (print x))*)> end;>> (*2*)> (*val _ = PolyML.addPrettyPrinter (fn _ => fn _ => fn x =>> PolyML.PrettyString (A.print x))*)> >> ML A.a; A.Test A.a; A.BAD A.a>>> This leads to a mix of results, depending on the place where the pretty> printer is installed.>> I still don't see how to get a simple and robust pretty printer setup,> so we can't use opaque ascription unless David Matthews wants to> refine that again for a future release of Poly/ML.>>> Makarius>>

Pasquale Noce continues his work on noninterference in CSP, this time considering concurrent composition. More details below. Many thanks, Pasquale!Larry PaulsonIn his outstanding work on Communicating Sequential Processes, Hoare has defined two fundamental binary operations allowing to compose the input processes into another, typically more complex, process: sequential composition and concurrent composition. Particularly, the output of the latter operation is a process in which any event not shared by both operands can occur whenever the operand that admits the event can engage in it, whereas any event shared by both operands can occur just in case both can engage in it.This paper formalizes Hoare's definition of concurrent composition and proves, in the general case of a possibly intransitive policy, that CSP noninterference security is conserved under this operation. This result, along with the previous analogous one concerning sequential composition, enables the construction of more and more complex processes enforcing noninterference security by composing, sequentially or concurrently, simpler secure processes, whose security can in turn be proven using either the definition of security, or unwinding theorems.http://www.isa-afp.org/entries/Noninterference_Concurrent_Composition.shtml

Hi Andreas,there is a brief description of the algorithm in my thesis in 4.3. That description should give you a good overview how the procedure works.I can answer additional questions if needed.Bests,OndrejOn 06/10/2016 05:32 PM, Andreas Lochbihler wrote:> Dear Lifting experts,>> I am looking for some documentation on how the Lifting tool derives the> parametrised transfer rules from the parametricity theorem. In some> cases, lift_definition reports that it was not able to merge certain> terms. I'd like to understand how this works and its limitations. I have> a different application in mind (strengthening parametricity theorems> with congruence rules) and would like to understand whether the same> approach could work there.>> Best,> Andreas>

Dear Ondrej,Thanks for the pointer. The last sentence of this section is what I am wondering about: I implemented a procedure that can do all of those steps automatically.The problem is that the function relator rel_fun does not distribute over relation composition op OO. The comment in Lifting.thy indicates that the theorems pos_fun_distr, neg_fun_distr1, and neg_fun_distr2 take the role of distributivity for functions. It seems as if the latter two are used only for higher-order arguments, but it is not yet clear to me which of the two covers which cases.They have preconditions on the relations like left_unique and right_total. How do you make sure that they can be used for the relations? neg_fun_distr2 only has assumptions about the relations on the right hand side of OO, so this will affect only the correspondence relation, so lift_definition has some control over this. But what about neg_fun_distr1 and its assumptions on relations on the left?Also, one could prove two more rules of the kind of neg_fun_distr1 and neg_fun_distr2. For example,lemma neg_fun_distr3: assumes 1: "left_unique R" "right_total R" and 2: "right_unique S" "left_total S" shows "R OO R' ===> S OO S' (R ===> S) OO (R' ===> S')" using functional_converse_relation[OF 1] functional_relation[OF 2] unfolding rel_fun_def OO_def apply clarify apply (subst all_comm) apply (subst all_conj_distrib[symmetric]) apply (intro choice) by metisWhy are these rules not needed?Best,AndreasOn 13/06/16 20:08, Ondej Kun?ar wrote:> Hi Andreas,> there is a brief description of the algorithm in my thesis in 4.3. That description> should give you a good overview how the procedure works.>> I can answer additional questions if needed.>> Bests,> Ondrej>> On 06/10/2016 05:32 PM, Andreas Lochbihler wrote:>> Dear Lifting experts,>>>> I am looking for some documentation on how the Lifting tool derives the>> parametrised transfer rules from the parametricity theorem. In some>> cases, lift_definition reports that it was not able to merge certain>> terms. I'd like to understand how this works and its limitations. I have>> a different application in mind (strengthening parametricity theorems>> with congruence rules) and would like to understand whether the same>> approach could work there.>>>> Best,>> Andreas>>>>

Thanks to Florian, Makarius and David for the explanations.Jrgen-----Original Message-----From: cl-isabelle-users-bounces at lists.cam.ac.uk [mailto:cl-isabelle-users-bounces at lists.cam.ac.uk] On Behalf Of David MatthewsSent: 13. juni 2016 13:36To: Makarius; cl-isabelle-users at lists.cam.ac.ukCc: PolyML mailing listSubject: Re: [isabelle] Opaque ascription for SML code generationPretty-printing isn't part of the ML standard so it's not always clear how to do it properly. There have been various changes over the years. In particular, printing exception packets is difficult because the packet can contain values of types that exist only where the exception is raised. In the example below, "t" may not actually be exported from the signature. So, Poly/ML puts the print function that applies where the exception is raised into the exception packet and uses that if it needs to print the packet. There are no plans to change this.There have been some changes around the printing of types exported through opaque matching. When a structure matches a signature containing a type through opaque matching the semantics says that this creates a new type "name". Poly/ML creates a new ref to hold the pretty print function for the new type. Previously this was initialised to the pretty print function for the implementing type but this was changed in5.6.1 to default to printing "?". It later became clear that this was too restrictive when the signature contained a datatype (e.g. "test" below) so there was a further change in commit 29985b1c in git master. So now if you install pretty printers both within the structure, (*1*) below, for the exception, and outside the signature (*2*) it will work as you expect.DavidOn 12/06/2016 15:22, Makarius wrote:> After the Isabelle2016 release, we have discontinued SML/NJ and old > versions of Poly/ML, so there is a bit more flexibility now in > canonical patterns for Isabelle/ML.>> The example with structure A3 from above is the difficult one, notably > the situation "does not work (overrides pp for int)". Defining the pp > outside of the structure basically works, but exceptions are not > printed correctly. This is how the problem with opaque ascription was > discovered many years ago, and the abstype solution took over.>>> Here is an update of the example A3 from Stackoverflow above, using> Isabelle2016 with its bundled Poly/ML 5.6:>> ML structure A :>> sig> type t> exception BAD of t> datatype test = Test of t> val a: t> val print: t -> string> end => struct>> type t = int>> exception BAD of t> datatype test = Test of t>> val a = 42>> fun print i = "{" ^ Int.toString i ^ "}">> (*1*)> (*val _ = PolyML.addPrettyPrinter (fn _ => fn _ => fn x => > PolyML.PrettyString (print x))*) end;>> (*2*)> (*val _ = PolyML.addPrettyPrinter (fn _ => fn _ => fn x => > PolyML.PrettyString (A.print x))*) >>> ML >>> This leads to a mix of results, depending on the place where the > pretty printer is installed.>> I still don't see how to get a simple and robust pretty printer setup, > so we can't use opaque ascription - unless David Matthews wants to > refine that again for a future release of Poly/ML.>>> Makarius>>

Hi,Why do I get the type "nibble" for the attached file?Thanks,Jrgen

theory Scratch imports Main "~~/src/HOL/Library/Code_Char" begindatatype foo = Foo String.literaldefinition bar :: foo where "bar \ Foo (STR ''='')"export_code bar in SML module_name Barend

Hi Jrgen,The char type is defined in HOL as a pair of nibbles, and String.literal in terms of lists of characters. For code generation, String.literal is mapped to strings in the target language, but this happens only after the code generator has gone over the internal construction of types. So it does not realise that nibble is not needed at all.Hope this helps,AndreasOn 14/06/16 18:57, Jrgen Villadsen wrote:> Hi,>> Why do I get the type "nibble" for the attached file?>> Thanks,>> Jrgen>

[Please post - apologies for multiple copies.]Second Call for Papers----------------------------------------Special issue of theJOURNAL OF SYMBOLIC COMPUTATIONonSYMBOLIC COMPUTATION IN SOFTWARE SCIENCE----------------------------------------http://www.risc.jku.at/~tkutsia/organization/jsc-scss-2016.htmlIMPORTANT DATES---------Abstract submission: June 27, 2016Paper submission: July 11, 2016Notification: October 17, 2016Publication: 2017SCOPE--------Symbolic Computation is the science of computing with symbolic objects(terms, formulae, programs, representations of algebraic objects etc.).Powerful symbolic algorithms and methods have been developed during thepast decades like computer algebra, theorem proving, automatedreasoning, software verification, model checking, rewriting,formalization of mathematics, Groebner bases, characteristic sets,telescoping for recurrence relations, cylindric algebraic decompositionand other quantifier elimination techniques, etc.The purpose of this special issue is to promote research on theoreticaland practical aspects of symbolic computation in software science. Thespecial issue is related to the topics of the International Symposium onSymbolic Computation in Software Science: SCSS 2014 and SCSS 2016. Itwill be published by Elsevier within the Journal of Symbolic Computation.Participants of the SCSS 2014 and SCSS 2016 symposia, as well as otherauthors are invited to submit contributions.EXAMPLES of TOPICS-------------------This special issue solicits papers on all aspects of symboliccomputation and their applications in software sciences. The topicsinclude, but are not limited to the following: - automated reasoning - algorithm (program) synthesis and/or verification - formal methods for the analysis of network and system security - termination analysis and complexity analysis of algorithms (programs) - extraction of specifications from algorithms (programs) - related theorem proving methods and techniques - proof carrying code - generation of inductive assertion for algorithm (programs) - algorithm (program) transformations - formalization and computerization of knowledge (maths, medicine,economy, etc.) - component-based programming - computational origami - query languages (in particular for XML documents) - semantic web and cloud computingSUBMISSION GUIDELINES---------------------This special issue welcomes original high-quality contributions thathave been neither published in nor simultaneously submitted to anyjournals or refereed conferences. Submissions will be peer-reviewedusing the standard refereeing procedure of the Journal of SymbolicComputation.Authors of papers presented at the SCSS 2014 and SCSS 2016 symposia arewelcome and encouraged to submit extended and revised versions of theirpapers. Furthermore, submissions of papers that are in the scope ofSCSS, but did not appear in SCSS 2014 and SCSS 2016 are welcome as well.Submitted papers must be in English and include a well writtenintroduction explicitly addressing the following questions in succinctand informal manner: - What is the problem? - Why is the problem important? - What has been done so far on the problem? - What is the main contribution of the paper on the problem? - Why is the contribution original? (Clarification: The results,already appeared in the conference paper, will be still counted as anoriginal result for JSC refereeing process.) - Why is the contribution non-trivial? - How is the journal paper different from the conference paper? (Forsubmissions originated from the papers presented at the symposium.)The submissions should be complete (since there is no rigid page limit): - All the related works and issues must be completely and carefullydiscussed. - All the previous relevant JSC papers must be properly cited anddiscussed. - All the theorem must be rigorously proved (no sketch allowed). - All the important definitions/theorems/algorithms must be illustratedby well chosen examples.Submissions originated from the papers presented at the symposium shouldaddress all the feedback from the symposium's referee process and Q/A.SUBMISSION--------------------Please prepare your submission in LaTeX using the JSC document formatfrom http://www4.ncsu.edu/~hong/jsc.htm(link to the submission template:http://www4.ncsu.edu/~hong/jsc/JSC_LaTex_2007_Mar_12.zip.)Submission is via the EasyChair submission site athttps://easychair.org/conferences/?conf=jscscss2016.GUEST EDITORS--------------------James H. Davenport (University of Bath, UK)Temur Kutsia (RISC, Johannes Kepler University Linz, Austria)

Hello list,I would like to prepare code exportation within a locale, in such a way that I only have to instantiate the locale to generate code later. However, my functions do not unconditionally terminate and I need an invariant (called inv in the following email) to prove termination and correctness. Therefore, I wanted to define a typedef within the locale. But as there cannot be a typedef inside a locale, I axiomatised it (via the theorem that typedef generates) with the idea that I could instantiate it later, while still using the theorems and lift definitions:locale type_definition_locale = fixes Abs :: "'a 'inv" and Rep :: "'inv 'a" and inv :: "'a bool" assumes Rep_inverse: "Abs (Rep x) = x" and Rep: "Rep x {a. inv a}" and Rep_inject: "Rep x = Rep y x = y" and Abs_inverse: "z {a. inv a} Rep (Abs z) = z" and Abs_induct: "(y. y {a. inv a} P (Abs y)) P y" and Rep_induct: "z {a. inv a} (z. P' (Rep z)) P' z" and Abs_cases: "(y. x = Abs y y {a. inv a} Q) Q" and Rep_cases: "z {a. inv a} (y. z = Rep y Q) Q" and Abs_inject: "z {a. inv a} z' {a. inv a} Abs z = Abs z' z = z'"Now my question is the following: is there a way to use lift_definition within the previous locale? For now, an error is produced:context type_definition_localebegindefinition raw_K :: "'a 'a 'a" where"raw_K a _ = a"lift_definition refined_K :: "'inv 'inv 'inv" is raw_K (* Fails with: Lifting failed for the following term: Term: raw_K Type: 'a 'a 'a Reason: The type of the term cannot be instantiated to "'inv 'inv inv. *)endI tried using setup_lifting, but this does not work either. The error message was not very precise ("The abstract type must be a type constructor.), but I think that the error comes from:fun is_Type (Type _) = true | is_Type _ = falseTypes passed as parameters in locales use the constructor TFree instead of Type.Is there a way to avoid doing the lifting by hand? Would it be safe to extend the function is_Type to accept TFree?Thanks in advance,Mathias

To whom it may concern.Isabelle2014 (August 2014) is the last version that can still be usedwith Proof General Emacs. On 31-Oct-2014 the last remains of the old TTYloop have been removed. See alsohttp://sketis.net/2014/discontinuation-of-isabelle-proof-general --especially the closing remark:> It should be noted that the general PIDE protocol infrastructure is sufficiently flexibile to support old-fashioned stepping through proof scripts as well, maybe even with some Emacs front-end. So Proof General veterans who do care enough about that may assemble at the proofgeneral-devel mailing list to prove that this old warrior is not-quite-dead yet.People who are still interested in Emacs have now a last chance to joinhttp://lists.inf.ed.ac.uk/mailman/listinfo/proofgeneral-devel before allold provers are removed, and Proof General becomes a Coq-only front-end.I actually support that move: there is no point to keep obsolete proverinterfaces and prevent renovation of Proof General for the Coq-8.5prover interaction protocol.Makarius

Dear Mathias,The Lifting package manages the registered quotients in a map with the name of the type constructor as a key. So even if you could trick setup_lifting into accepting a theorem of the form type_definition Rep Abs {x. inv x}the lift_definition command would not be able to find the setup, because it constructs the lifting relation based on the type constructors that appear in the types of the raw term and the lifted constant. One would have to extend the implementation of Lifting_Term.prove_schematic_quot_thm accordingly to also support TFree.Moreover, you'd have to make sure that the quotient theorem setup does not leak into any interpretation, in which the type variables get instantiated or generalised. Otherwise, the internal data structures of the Lifting package would be messed up.Finally, I am not sure that your approach will actually work for code generation. The steps of lift_definition for a subtype copy are fairly limited except when it comes to code generation for compound return types. For example, if your function returns something like 'inv list (rather than a plain 'inv), then lift_definition internally generates a number of types and auxiliary constants and lifts the invariant to those types such that the code generator can handle them. I cannot see how this construction would work for an unspecified 'inv (otherwise, we could have done the construction once and for all for such an arbitrary 'inv and then just reused everything).AndreasOn 15/06/16 20:44, Mathias Fleury wrote:> Hello list,>> I would like to prepare code exportation within a locale, in such a way that I only have to instantiate the locale to generate code later. However, my functions do not unconditionally terminate and I need an invariant (called inv in the following email) to prove termination and correctness. Therefore, I wanted to define a typedef within the locale.>> But as there cannot be a typedef inside a locale, I axiomatised it (via the theorem that typedef generates) with the idea that I could instantiate it later, while still using the theorems and lift definitions:>> locale type_definition_locale => fixes Abs :: "'a 'inv" and Rep :: "'inv 'a" and inv :: "'a bool"> assumes> Rep_inverse: "Abs (Rep x) = x" and> Rep: "Rep x {a. inv a}" and> Rep_inject: "Rep x = Rep y x = y" and> Abs_inverse: "z {a. inv a} Rep (Abs z) = z" and> Abs_induct: "(y. y {a. inv a} P (Abs y)) P y" and> Rep_induct: "z {a. inv a} (z. P' (Rep z)) P' z" and> Abs_cases: "(y. x = Abs y y {a. inv a} Q) Q" and> Rep_cases: "z {a. inv a} (y. z = Rep y Q) Q" and> Abs_inject: "z {a. inv a} z' {a. inv a} Abs z = Abs z' z = z'">>> Now my question is the following: is there a way to use lift_definition within the previous locale? For now, an error is produced:>> context type_definition_locale> begin>> definition raw_K :: "'a 'a 'a" where> "raw_K a _ = a">> lift_definition refined_K :: "'inv 'inv 'inv" is raw_K>> (* Fails with:> Lifting failed for the following term:> Term: raw_K> Type: 'a 'a 'a>> Reason:> The type of the term cannot be instantiated to> "'inv 'inv inv?.> *)> end>> I tried using setup_lifting, but this does not work either. The error message was not very precise ("The abstract type must be a type constructor.?), but I think that the error comes from:>> fun is_Type (Type _) = true> | is_Type _ = false>> Types passed as parameters in locales use the constructor TFree instead of Type.>>> Is there a way to avoid doing the lifting by hand? Would it be safe to extend the function is_Type to accept TFree?>>> Thanks in advance,> Mathias>

Hi Mathias,quoting NEWS for Isabelle2099-2:> * Command 'typedef' now works within a local theory context -- without> introducing dependencies on parameters or assumptions, which is not> possible in Isabelle/Pure/HOL. Note that the logical environment may> contain multiple interpretations of local typedefs (with different> non-emptiness proofs), even in a global theory context.I do not know whether your typedef specification satisfy theprecondition that no depend