Review History

All reviews of published articles are made public. This includes manuscript files, peer review comments, author rebuttals and revised materials. Note: This was optional for articles submitted before 13 February 2023.

Peer reviewers are encouraged (but not required) to provide their names to the authors when submitting their peer review. If they agree to provide their name, then their personal profile page will reflect a public acknowledgment that they performed a review (even if the article is rejected). If the article is accepted, then reviewers who provided their name will be associated with the article itself.

View examples of open peer review.


  • The initial submission of this article was received on June 25th, 2020 and was peer-reviewed by 2 reviewers and the Academic Editor.
  • The Academic Editor made their initial decision on July 29th, 2020.
  • The first revision was submitted on October 13th, 2020 and was reviewed by 1 reviewer and the Academic Editor.
  • The article was Accepted by the Academic Editor on October 29th, 2020.

Version 0.2 (accepted)

· Oct 29, 2020 · Academic Editor


As you can see, the reviewer was very happy with your changes.

Reviewer 2 ·

Basic reporting

The author addressed my points in a satisfactory manner.
Therefore, I am happy to confirm the positive overall assessment of the paper expressed in my previous review.

Experimental design

The author addressed my points in a satisfactory manner.
Therefore, I am happy to confirm the positive overall assessment of the paper expressed in my previous review.

Validity of the findings

The author addressed my points in a satisfactory manner. In particular, I am happy with the technical explanation addressing the question about currying.
Therefore, I am happy to confirm the positive overall assessment of the paper expressed in my previous review.

Additional comments

The diff paper version and the colour-coded rebuttal eased my job: I would like to thank the author for the appreciated effort.

Version 0.1 (original submission)

· Jul 29, 2020 · Academic Editor

Major Revisions

Please address the comments raised by the reviewers. In particular, I would like you to clarify the overall research objective, and to address the point raised by reviewer 2 about the relation between contribution 1 and 2 and currying.

[# PeerJ Staff Note: Please ensure that all review comments are addressed in a rebuttal letter and any edits or clarifications mentioned in the letter are also inserted into the revised manuscript where appropriate.  It is a common mistake to address reviewer questions in the rebuttal letter but not in the revised manuscript. If a reviewer raised a question then your readers will probably have the same question so you should ensure that the manuscript can stand alone without the rebuttal letter.  Directions on how to prepare a rebuttal letter can be found at: #]

[# PeerJ Staff Note: The review process has identified that the English language must be improved. PeerJ can provide language editing services - please contact us at for pricing (be sure to provide your manuscript number and title) #]

Reviewer 1 ·

Basic reporting

The language and article format of the manuscript
should be checked to communicate meaning clearly and
use professional English as much as possible.

For example:

Line 54 - rather than "a bunch of computer programs",
perhaps "a collection of computer programs"

Line 94 - "...permissive assumptions are missed" means
"...permissive assumptions are omitted"?

Line 119 - in place of "...variables are permitted what
enables to introduce schemes", "...variables are permitted
which enables the introduction of schemes" or "...variables
are permitted enabling the introduction of schemes" might
be better

Table 1 - table title should be placed above the table

Experimental design

The research objective (or main questions that
need to be answered) should be clarified in the
abstract and paper, especially from a computer science
standpoint. The journal does not accept case studies
or case reports.

Validity of the findings

The author makes a good effort to make the
contents of the paper self-contained, but it
is difficult to link the conclusion to the
research question (which should be revised
and clarified in the experimental design) of
the work.

Reviewer 2 ·

Basic reporting

The paper is written in a clear and understandable form.
Sections 1,2 and 3 give a rich and complete snapshot of the current state of the verification research revolving around the Mizar proof checker.

I only have some minor remarks about style and form, reported below.

In the abstract, the apposition "proof-assistant" explaining what Mizar is only appears at its second occurrence.
It would be better to qualify Mizar at its first occurrence.

'"Property" in Mizar is a construction that can be used to...': reads strange.
What about 'Properties in Mizar are keywords that can be used to...' or
'A property in Mizar is a construction that can be used to...'?

l67: "ways how" -> "how"
l184: The "Next submodule"
l190: "much reacher"
l424: "properties of used in the theorems functors."

Experimental design

Section 3 provides a detailed background of the role of properties in the Mizar language and of their current limitations.
This allows the author to clearly point out what the paper contributes.
Again, I only have minor remarks about some points where there possibly is some technicalities excess.

The word "functor" has usually a different meaning in mathematics and theoretical computer science, coming from category theory. Perhaps the reader should be warned about this.
There are other instances where specific Mizar jargon is used and where some reference or explanation would benefit the reader. For example, l71: permissive assumption.

line 30: to satisfy the interested reader, it would be better to have a reference which uses identifications or explain what they are.

Validity of the findings

The contributions of the paper are:
1) a generalisation of the existing properties feature of Mizar allowing to apply them to functions/operations of arbitrary arities;
2) correspondingly, an optional, additional "wrt" keyword allowing the user to precisely specify which arguments of the function/operation are affected by the property;
3) a new property (fixpoint-free)

1 and 2 are formally described in section 3, and 3) in section 4.
Wrt 3), some small investigation about its impact on MML is proposed.
I am surprised that only 3 occurrences have been found; I don't think this means the new property is useless.
On the contrary, I suspect many more occurrences can be found, making it useful.
There are many numerical functions satisfying this property. Even not taking into account functions whose output type differs from their arguments' types, which should automatically satisfy that property.

Regarding 1) and 2), section 3.2 is important for researchers working within (as opposed to merely using) theorem proving.

If I may suggest a possible line of further investigation: 1) and 2) seem intimately related to the notion of currying, which I understand is defined in MML. Would that be possible to link the two things together? If yes (and I am not sure, given the first-order nature of Mizar!), how?

The small example at the end of section 3.1 is intriguing: I understand that some properties are not enforceable at definition time because they only apply to a subclass of the defined items. However, is there a workaround in such cases, maybe based on cluster registrations?

All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.