diff --git a/metadata/templates/about.tpl b/metadata/templates/about.tpl --- a/metadata/templates/about.tpl +++ b/metadata/templates/about.tpl @@ -1,76 +1,76 @@ {% extends "base.tpl" %} {% block headline %} Archive of Formal Proofs {% endblock %} {% block content %}

About

The Archive of Formal Proofs is a collection of proof libraries, examples, and larger scientific developments, mechanically checked in the theorem prover Isabelle. It is organized in the way of a scientific journal. Submissions are refereed.

-

The archive repository is hosted on Bitbucket to +

The archive repository is hosted on Heptapod to provide easy free access to archive entries. The entries are tested and maintained continuously against the current stable release of Isabelle. Older versions of archive entries will remain available.

Editors

The editors of the archive are

Why

We aim to strengthen the community and to foster the development of formal proofs.

We hope that the archive will provide

  • a resource of knowledge, examples, and libraries for users,
  • a large and relevant test bed of theories for Isabelle developers, and
  • a central, citable place for authors to publish their theories

We encourage authors of publications that contain Isabelle developments to make their theories available in the Archive of Formal Proofs and to refer to the archive entry in their publication. It makes it easier for referees to check the validity of theorems (all entries in the archive are mechanically checked), it makes it easier for readers of the publication to understand details of your development, and it makes it easier to use and build on your work.

License

-

All entries in the Archive of Formal Proofs are licensed under +

All entries in the Archive of Formal Proofs are licensed under a BSD-style License or the GNU LGPL. This means they are free to download, free to use, free to change, and free to redistribute with minimal restrictions.

The authors retain their full copyright on their original work, -including their right to make the development available under another, +including their right to make the development available under another, additional license in the future.

{% endblock %} diff --git a/metadata/templates/status.tpl b/metadata/templates/status.tpl --- a/metadata/templates/status.tpl +++ b/metadata/templates/status.tpl @@ -1,62 +1,62 @@ {% extends "base.tpl" %} {% block headline %} Archive of Formal Proofs {% endblock %} {% block content %}

Test status of entries in the AFP development version

Isabelle revision: {{ build_data.isabelle_id }}
AFP revision: - + {{ build_data.afp_id }}
Build time:{{ build_data.time }}
Build URL:Jenkins
Job name:{{ build_data.job }}

 

{% for entry in entries %} {% endfor %}
[{{entry.status}}] {{entry.name}}
{% endblock %} diff --git a/metadata/templates/submitting.tpl b/metadata/templates/submitting.tpl --- a/metadata/templates/submitting.tpl +++ b/metadata/templates/submitting.tpl @@ -1,87 +1,87 @@ {% extends "base.tpl" %} {% block headline %} Submission Guidelines {% endblock %} {% block content %}

Please send your submission via this web page.

The submission must follow the following Isabelle style rules. For additional guidelines on Isabelle proofs, also see the this guide (feel free to follow all of these; only the below are mandatory). Technical details about the submission process and the format of the submission are explained on the submission site.

  • No use of the commands sorry or back.
  • Instantiations must not use Isabelle-generated names such as xa — use Isar, the subgoal command or rename_tac to avoid such names.
  • No use of the command smt_oracle.
  • If your theories contain calls to nitpick, quickcheck, or nunchaku those calls must include the expect parameter. Alternatively the expect parameter must be set globally via, e.g. nitpick_params.
  • apply scripts should be indented by subgoal as in the Isabelle distribution. If an apply command is applied to a state with n+1 subgoals, it must be indented by n spaces relative to the first apply in the sequence.
  • Only named lemmas should carry attributes such as [simp].
  • We prefer structured Isar proofs over apply style, but do not mandate them.
  • If there are proof steps that take significant time, i.e. longer than roughly 1 min, please add a short comment to that step, so maintainers will know what to expect.
  • The entry must contain a ROOT file with one session that has the name of the entry. We strongly encourage precisely one session per entry, but exceptions can be made. All sessions must be in group (AFP), and all theory files of the submission must be contained in - at least one session. See also the example ROOT file + at least one session. See also the example ROOT file in the Example submission.
  • The entry should cite all sources that the theories are based on, for example textbooks or research articles containing informal versions of the proofs.

Your submission must contain an abstract to be displayed on the web site – usually this will be the same as the abstract of your proof document in the root.tex file. You can use LaTeX formulae in this web site abstract, either inline formulae in the form $a+b$ or \(a+b\) or display formulae in the form $$a + b$$ or \[a + b\]. Other occurrences of these characters must be escaped (e.g. \$ or \\(). Note that LaTeX in the title of an entry is not allowed. Most basic LaTeX functionality should be supported. For details on what parts of LaTeX are supported, see the MathJax documentation.

It is possible and encouraged to build on other archive entries in your submission. There is a standardised way to refer to other AFP entries in your theories.

Your submission will be refereed and you will receive notification as soon as possible. If accepted, you must agree to maintain your archive entry or nominate someone else to maintain it. The Isabelle development team will assist with maintenance, but it does not have the resources to fully maintain the complete archive.

If you have questions regarding your submission, please email afp-submit@in.tum.de. If you need help with Isabelle, please use the isabelle-users@cl.cam.ac.uk mailing list. It is always a good idea to subscribe.

{% endblock %} diff --git a/metadata/templates/updating.tpl b/metadata/templates/updating.tpl --- a/metadata/templates/updating.tpl +++ b/metadata/templates/updating.tpl @@ -1,102 +1,102 @@ {% extends "base.tpl" %} {% block headline %} Updating Entries {% endblock %} {% block content %}

Change

The Archive of Formal Proofs is an online resource and therefore more dynamic than a normal scientific journal. Existing entries can and do evolve and can also be updated significantly by their authors.

This conflicts with the purpose of archiving and preserving -entries as they have been submitted and with the purpose of +entries as they have been submitted and with the purpose of providing a clear and simple interface to readers.

The AFP deals with this by synchronizing such updates with Isabelle releases:

  • The entries released and visible on the main site are always working with the most recent stable Isabelle version and do not change.
  • In the background, the archive maintainers evolve all entries to be up to date with the current Isabelle development version. Authors can contribute changes to this version which is available as a bitbucket +href="https://foss.heptapod.net/isa-afp/afp-devel/">Heptapod mercurial repository or as tar.gz package on the download page.
  • When a new Isabelle version is released, the above mentioned development version of AFP is frozen and turns into the main version displayed on the front page. Older versions (including the original submission) of all entries are archived and remain accessible.

Significant changes of an entry should be recorded in the metadata of the entry using the keyword "extra-history". The resulting web page should look something like this.

Monotonicity

Updating an entry should be mostly monotone: you add new material, but you do not modify existing material in a major way. Ideally, entries (by other people) that build on yours should not be affected. Otherwise you have to liaise with them first. If you intend to carry out major non-monotone changes, you will need to submit a completely new entry (with a description of how it relates to the old one). This should be required only very rarely: AFP entries should be mature enough not to require major changes to their interface (i.e. the main functions and theorems provided).

Major monotone changes, e.g. adding a new concept rather than more results on existing concepts, may also call for a new entry, but one that builds on the existing one. This depends on how you would like to organize your entries.

If you are an author

The above means that if you are an author and would like to provide a new, better version of your AFP entry, you can do so.

To achieve this, you should base your changes on the mercurial +href="https:/foss.heptapod.net/isa-afp/afp-devel/">mercurial development version of your AFP entry and test it against the current Isabelle development version.

-If you would like to get write access to your entry in the +If you would like to get write access to your entry in the mercurial repository or if you need assistance, please contact the editors.

{% endblock %} diff --git a/web/about.html b/web/about.html --- a/web/about.html +++ b/web/about.html @@ -1,144 +1,144 @@ Archive of Formal Proofs

 

 

 

 

 

 

Archive of Formal Proofs

 

About

The Archive of Formal Proofs is a collection of proof libraries, examples, and larger scientific developments, mechanically checked in the theorem prover Isabelle. It is organized in the way of a scientific journal. Submissions are refereed.

-

The archive repository is hosted on Bitbucket to +

The archive repository is hosted on Heptapod to provide easy free access to archive entries. The entries are tested and maintained continuously against the current stable release of Isabelle. Older versions of archive entries will remain available.

Editors

The editors of the archive are

Why

We aim to strengthen the community and to foster the development of formal proofs.

We hope that the archive will provide

  • a resource of knowledge, examples, and libraries for users,
  • a large and relevant test bed of theories for Isabelle developers, and
  • a central, citable place for authors to publish their theories

We encourage authors of publications that contain Isabelle developments to make their theories available in the Archive of Formal Proofs and to refer to the archive entry in their publication. It makes it easier for referees to check the validity of theorems (all entries in the archive are mechanically checked), it makes it easier for readers of the publication to understand details of your development, and it makes it easier to use and build on your work.

License

-

All entries in the Archive of Formal Proofs are licensed under +

All entries in the Archive of Formal Proofs are licensed under a BSD-style License or the GNU LGPL. This means they are free to download, free to use, free to change, and free to redistribute with minimal restrictions.

The authors retain their full copyright on their original work, -including their right to make the development available under another, +including their right to make the development available under another, additional license in the future.

\ No newline at end of file diff --git a/web/statistics.html b/web/statistics.html --- a/web/statistics.html +++ b/web/statistics.html @@ -1,307 +1,307 @@ Archive of Formal Proofs

 

 

 

 

 

 

Statistics

 

Statistics

Number of Articles:545
Number of Authors:359
Number of lemmas:~147,600
Lines of Code:~2,568,200

Most used AFP articles:

NameUsed by ? articles
1. List-Index 15
2. Coinductive 12
Collections 12
Regular-Sets 12
3. Landau_Symbols 11
4. Show 10
5. Abstract-Rewriting 9
Automatic_Refinement 9
Deriving 9
Polynomial_Factorization 9
6. Jordan_Normal_Form 8
Native_Word 8

Growth in number of articles:

Growth in lines of code:

Growth in number of authors:

Size of articles:

\ No newline at end of file diff --git a/web/submitting.html b/web/submitting.html --- a/web/submitting.html +++ b/web/submitting.html @@ -1,155 +1,155 @@ Archive of Formal Proofs

 

 

 

 

 

 

Submission Guidelines

 

Please send your submission via this web page.

The submission must follow the following Isabelle style rules. For additional guidelines on Isabelle proofs, also see the this guide (feel free to follow all of these; only the below are mandatory). Technical details about the submission process and the format of the submission are explained on the submission site.

  • No use of the commands sorry or back.
  • Instantiations must not use Isabelle-generated names such as xa — use Isar, the subgoal command or rename_tac to avoid such names.
  • No use of the command smt_oracle.
  • If your theories contain calls to nitpick, quickcheck, or nunchaku those calls must include the expect parameter. Alternatively the expect parameter must be set globally via, e.g. nitpick_params.
  • apply scripts should be indented by subgoal as in the Isabelle distribution. If an apply command is applied to a state with n+1 subgoals, it must be indented by n spaces relative to the first apply in the sequence.
  • Only named lemmas should carry attributes such as [simp].
  • We prefer structured Isar proofs over apply style, but do not mandate them.
  • If there are proof steps that take significant time, i.e. longer than roughly 1 min, please add a short comment to that step, so maintainers will know what to expect.
  • The entry must contain a ROOT file with one session that has the name of the entry. We strongly encourage precisely one session per entry, but exceptions can be made. All sessions must be in group (AFP), and all theory files of the submission must be contained in - at least one session. See also the example ROOT file + at least one session. See also the example ROOT file in the Example submission.
  • The entry should cite all sources that the theories are based on, for example textbooks or research articles containing informal versions of the proofs.

Your submission must contain an abstract to be displayed on the web site – usually this will be the same as the abstract of your proof document in the root.tex file. You can use LaTeX formulae in this web site abstract, either inline formulae in the form $a+b$ or \(a+b\) or display formulae in the form $$a + b$$ or \[a + b\]. Other occurrences of these characters must be escaped (e.g. \$ or \\(). Note that LaTeX in the title of an entry is not allowed. Most basic LaTeX functionality should be supported. For details on what parts of LaTeX are supported, see the MathJax documentation.

It is possible and encouraged to build on other archive entries in your submission. There is a standardised way to refer to other AFP entries in your theories.

Your submission will be refereed and you will receive notification as soon as possible. If accepted, you must agree to maintain your archive entry or nominate someone else to maintain it. The Isabelle development team will assist with maintenance, but it does not have the resources to fully maintain the complete archive.

If you have questions regarding your submission, please email afp-submit@in.tum.de. If you need help with Isabelle, please use the isabelle-users@cl.cam.ac.uk mailing list. It is always a good idea to subscribe.

\ No newline at end of file diff --git a/web/updating.html b/web/updating.html --- a/web/updating.html +++ b/web/updating.html @@ -1,170 +1,170 @@ Archive of Formal Proofs

 

 

 

 

 

 

Updating Entries

 

Change

The Archive of Formal Proofs is an online resource and therefore more dynamic than a normal scientific journal. Existing entries can and do evolve and can also be updated significantly by their authors.

This conflicts with the purpose of archiving and preserving -entries as they have been submitted and with the purpose of +entries as they have been submitted and with the purpose of providing a clear and simple interface to readers.

The AFP deals with this by synchronizing such updates with Isabelle releases:

  • The entries released and visible on the main site are always working with the most recent stable Isabelle version and do not change.
  • In the background, the archive maintainers evolve all entries to be up to date with the current Isabelle development version. Authors can contribute changes to this version which is available as a bitbucket +href="https://foss.heptapod.net/isa-afp/afp-devel/">Heptapod mercurial repository or as tar.gz package on the download page.
  • When a new Isabelle version is released, the above mentioned development version of AFP is frozen and turns into the main version displayed on the front page. Older versions (including the original submission) of all entries are archived and remain accessible.

Significant changes of an entry should be recorded in the metadata of the entry using the keyword "extra-history". The resulting web page should look something like this.

Monotonicity

Updating an entry should be mostly monotone: you add new material, but you do not modify existing material in a major way. Ideally, entries (by other people) that build on yours should not be affected. Otherwise you have to liaise with them first. If you intend to carry out major non-monotone changes, you will need to submit a completely new entry (with a description of how it relates to the old one). This should be required only very rarely: AFP entries should be mature enough not to require major changes to their interface (i.e. the main functions and theorems provided).

Major monotone changes, e.g. adding a new concept rather than more results on existing concepts, may also call for a new entry, but one that builds on the existing one. This depends on how you would like to organize your entries.

If you are an author

The above means that if you are an author and would like to provide a new, better version of your AFP entry, you can do so.

To achieve this, you should base your changes on the mercurial +href="https:/foss.heptapod.net/isa-afp/afp-devel/">mercurial development version of your AFP entry and test it against the current Isabelle development version.

-If you would like to get write access to your entry in the +If you would like to get write access to your entry in the mercurial repository or if you need assistance, please contact the editors.

\ No newline at end of file