A Brief Overview of the Pawns Programming Language

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This article provides a comprehensive overview of the Pawns programming languag,it is a language that supports both pure functional and imperative programming with unique shared analysis and effects encapsulation featuresand ,and there ere are some opinion:

1. More specific code examples can be included, such as examples of unique features of the Pawns language.

2. The summary provides an overall overview, which can be considered extended to discuss the specific problems it addresses, and suggests that the motivation for developing "Pawns" can be strengthened.

3. It is advisable for the authors to enhance the literature review section by incorporating a discussion of additional languages and research contributions that have shaped Pawns' design philosophy.

4. The article employs numerous technical terminologies (including 'pointer aliases' and 'algebraic data types') and advocates for a concise explanation upon their initial mention.

5. It is recommended to use diagrams, etc., to help explain complex concepts and algorithms.

6. In the related working section, comparisons are made with languages such as Haskell, Mercury, and Discus. In addition to highlighting the differences, it is recommended to also discuss what these languages have in common with Pawns.

Author Response

1. More specific code examples can be included, such as examples of unique features o
f the Pawns language.

I've added a little more code but no larger examples.  I was tempted to use a
larger example with multiple state variables but it detracted from the point
about encapsulation. Other reviewers compained about the code being hard to
understand so I didn't want to add anything too complex (I also added
diagrams to help explain tings).

2. The summary provides an overall overview, which can be considered extended to disc
uss the specific problems it addresses, and suggests that the motivation for developi
ng "Pawns" can be strengthened.

I've added to this and also referred related work that has more extensive
discussion.
3. It is advisable for the authors to enhance the literature review section by incorp
orating a discussion of additional languages and research contributions that have sha
ped Pawns' design philosophy.

I've added quite a lot more detail to the related work section.
4. The article employs numerous technical terminologies (including 'pointer aliases' 
and 'algebraic data types') and advocates for a concise explanation upon their initia
l mention.

I've tried to make these more clear.
5. It is recommended to use diagrams, etc., to help explain complex concepts and algo
rithms.

Added for the cord code.

6. In the related working section, comparisons are made with languages such as Haskel
l, Mercury, and Discus. In addition to highlighting the differences, it is recommende
d to also discuss what these languages have in common with Pawns.

I've added quite a lot more detail to the related work section.

Reviewer 2 Report

Comments and Suggestions for Authors

- The authors should strengthen the work's uniqueness by offering a more detailed comparison with related languages and techniques, such as Haskell with monads, ML with refs, and Discus. 

- Currently, the study mentions potential efficiency increases, but specific experimental data or case studies would help back up these claims. 

Author Response

- The authors should strengthen the work's uniqueness by offering a more detailed com
parison with related languages and techniques, such as Haskell with monads, ML with r
efs, and Discus. 

I've added quite a lot more detail to the related work section.

- Currently, the study mentions potential efficiency increases, but specific experime
ntal data or case studies would help back up these claims. 

I've added more details (and moved this later)

Reviewer 3 Report

Comments and Suggestions for Authors

This paper describes some characteristics of a novel programming language - pawns. This language aims to offer both functional and imperative logic to programmers. The paper describes some of the attributes of the language without going into very detailed formal aspects about how the language works.
In summary, this paper is more akin to a dissemination publication than to one that actually provides answers to research questions. Thus, it does not have an impact as strong as paper that actually puts forward novel results/methodologies/etc.
That being said, I have no specific opposition to the paper itself, as it seems that its aims are exclusively to disseminate information about pawns. However, I do find some faults in the paper that need revision before publication.
- The abstract is not conformant to what a reader might expect in a academic paper. Try to focus these three main aspects in the abstract: the topic, the contribution, a brief summary of the methodology, a brief mention to results/conclusions. This way the reader gets an idea about what the paper is.
- There are quite a few typos and grammatical errors. This is more notable in the first half of the paper. There are too many issues to list here, and the paper must be revised in this aspect.
- Some sentences have an obscure or ambiguous meaning. For example, "add a lot to the attraction of functional programming" (page 2), "BST creation is unlikely to be a major time component" (page 3)".
- In the introduction it should be made very clear if the author of the paper is the author of the language.
- The paper lacks a proper related work/state of the art on languages that may fall in the same category as pawns. There are some references to the fact that other works and approaches exist, but there is no more information (what, by who, and how it relates/compares to this work). I do acknowledge the comparison of pawns against other languages such as Prolog and Haskell in page 17, However the issue described here is something else: a comparison to other approaches such as this work.
- Some claims are given without a formal or experimental basis. For example, in page 3, "a factor of around twenty in our experiments" -> it seems some sort of benchmarking results from experiments done in the context of this work. Describe that benchmark (what it is, what is the workload, how were the experiments done, etc.).
- Similarly to the previous issue: the paper makes some claims that need a citation to the work or publication that supports such claims. Sections 3 and 4 (but not just those) could benefit from proper citations.
- The code excerpt would benefit from a better explanation. It is hard to extract meaning from them. A description of the syntax would be helpful (or refer the source of where that information can be found).
- (suggestion) I would try to make the presentation on pages 9 and 10 less wordy and more concise.
- Section 10 would make more sense if it would follow the more classical approach of "threats to validity". A previous description of the state of the art would also help improving section 10
- The paper makes use of many concepts specific to this area that were not explained (examples: purity, destructive update, sharing, etc.). Some readers will understand, while others will not and, and this reduces the impact of the paper. Consider adding a section of "related concepts" after the introduction.
- The reference list is small. I am not suggesting inserting citations just to fill space. What I am saying is that the list of references is small because the paper lacks sections with related work, concepts and state of the art. When you correct those, you will see that the reference list will augment significatively.
It seems that a revision is needed for the author to solve these issues.
Comments on the Quality of English Language

The paper needs an extensive revision concerning the English usage, as noted in the comments to the authors.

Author Response

Thanks for the detailed review.

- The abstract is not conformant to what a reader might expect in a academic paper. T
ry to focus these three main aspects in the abstract: the topic, the contribution, a 
brief summary of the methodology, a brief mention to results/conclusions. This way th
e reader gets an idea about what the paper is.

Rewritten (this paper was originally written in a deliberately non-academic
style and is being transformed into a paper that hopefully meets academic
standards while still being relatively accessible to a wider audience).

- There are quite a few typos and grammatical errors. This is more notable in the fir
st half of the paper. There are too many issues to list here, and the paper must be r
evised in this aspect.

I've fixed a lot of them. Possibly not all - I'm resubmitting in a bit of a
hurry with a somewhat foggy brain but there should be an opportunity for minor
fixes later.

- Some sentences have an obscure or ambiguous meaning. For example, "add a lot to the
 attraction of functional programming" (page 2), "BST creation is unlikely to be a ma
jor time component" (page 3)".

I've tried to clarify a bunch of things.

- In the introduction it should be made very clear if the author of the paper is the 
author of the language.

Done.

- The paper lacks a proper related work/state of the art on languages that may fall i
n the same category as pawns. There are some references to the fact that other works 
and approaches exist, but there is no more information (what, by who, and how it rela
tes/compares to this work). I do acknowledge the comparison of pawns against other la
nguages such as Prolog and Haskell in page 17, However the issue described here is so
mething else: a comparison to other approaches such as this work.

I've made this section significantly more detailed for the more closely
related languages. I've avoided discussing not so closely related languages -
there are too many of them.

- Some claims are given without a formal or experimental basis. For example, in page 
3, "a factor of around twenty in our experiments" -> it seems some sort of benchmarki
ng results from experiments done in the context of this work. Describe that benchmark
 (what it is, what is the workload, how were the experiments done, etc.).

I've described the benchmark and added more discussion (plus moved this
later).

- Similarly to the previous issue: the paper makes some claims that need a citation t
o the work or publication that supports such claims. Sections 3 and 4 (but not just t
hose) could benefit from proper citations.

I've added a few more citations to the earlier part of the paper but mostly
leave discussion of related work to the section towards the end.

- The code excerpt would benefit from a better explanation. It is hard to extract mea
ning from them. A description of the syntax would be helpful (or refer the source of 
where that information can be found).

I've added a couple of diagrams to help with the cord code, and some (kind
of) C code that may help with the BST code. I mention that the syntax is
essentially Haskell with ; instead of `seq`, plus additions for the sharing
declarations that are described.

- Section 10 would make more sense if it would follow the more classical approach of 
"threats to validity". A previous description of the state of the art would also help
 improving section 10

I've added more related work, a summary of contributions plus threats to
validity.

- The paper makes use of many concepts specific to this area that were not explained 
(examples: purity, destructive update, sharing, etc.). Some readers will understand, 
while others will not and, and this reduces the impact of the paper. Consider adding 
a section of "related concepts" after the introduction.

I've not added a separate section but tried to explain a few things in more
detail along the way.

- The reference list is small. I am not suggesting inserting citations just to fill s
pace. What I am saying is that the list of references is small because the paper lack
s sections with related work, concepts and state of the art. When you correct those, 
you will see that the reference list will augment significatively.

The reference list is longer than is was...  See comments on related work.
I refer to a couple of PhD theses about the Mars and Disciple languages
but am trying to avoid (re)writing a PhD thesis chapter or two.

Round 2

Reviewer 3 Report

Comments and Suggestions for Authors

review 2024 - mdpi software - pawns 2a volta - 2024.10.25 draft of review as text.txt
Issue 1
-> First round comment - The abstract is not conformant to what a reader might expect in a academic paper. Try to focus these three main aspects in the abstract: the topic, the contribution, a brief summary of the methodology, a brief mention to results/conclusions. This way the reader gets an idea about what the paper is.
-> Your answer - Rewritten (this paper was originally written in a deliberately non-academic style and is being transformed into a paper that hopefully meets academic standards while still being relatively accessible to a wider audience).
-> Second Round Comment - The abstract was indeed improved but it is not there yet. It need further improvement.

Issue 2
-> First round comment - There are quite a few typos and grammatical errors. This is more notable in the first half of the paper. There are too many issues to list here, and the paper must be revised in this aspect.
-> Your answer - I've fixed a lot of them. Possibly not all - I'm resubmitting in a bit of a hurry with a somewhat foggy brain but there should be an opportunity for minor fixes later.
-> Second Round Comment - The typo issue was improved. However, I have to say this your answer, concerning the fogginess of brain, is probably the weirdest answer I have seen in an author reply.

Issue 3
-> First round comment - Some sentences have an obscure or ambiguous meaning. For example, "add a lot to the attraction of functional programming" (page 2), "BST creation is unlikely to be a major time component" (page 3)".
-> Your answer - I've tried to clarify a bunch of things.
-> Second Round Comment - This was improved, but it is not yet solved. You still have vague statements. Some examples: What are those various new language features mentioned at the start f the introduction? Would it make a stronger case to enumerate them right at the star of the motivation statement? What are the "various languages features and compiler analyses" mentioned near the beginning of section 12? What is a "rather old" x86_64 laptop? How recent is a "recent version" of Ububtu Linux? And, for that matter, how much is a "bunch" (in your answer)? The vagueness is not appropriate to a scientific publication, and the informal discourse is also not adequate. This needs to be fixed.

Issue 4
-> First round comment - In the introduction it should be made very clear if the author of the paper is the author of the language.
-> Your answer - Done.
-> Second Round Comment - ok

Issue 5
-> First round comment - The paper lacks a proper related work/state of the art on languages that may fall in the same category as pawns. There are some references to the fact that other works and approaches exist, but there is no more information (what, by who, and how it relates/compares to this work). I do acknowledge the comparison of pawns against other languages such as Prolog and Haskell in page 17, However the issue described here is something else: a comparison to other approaches such as this work.
-> Your answer - I've made this section significantly more detailed for the more closely related languages. I've avoided discussing not so closely related languages - there are too many of them.
-> Second Round Comment - ok

Issue 6
-> First round comment - Some claims are given without a formal or experimental basis. For example, in page 3, "a factor of around twenty in our experiments" -> it seems some sort of benchmarking results from experiments done in the context of this work. Describe that benchmark (what it is, what is the workload, how were the experiments done, etc.).
-> Your answer - I've described the benchmark and added more discussion (plus moved this later).
-> Second Round Comment - ok

Issue 7
-> First round comment - Similarly to the previous issue: the paper makes some claims that need a citation to the work or publication that supports such claims. Sections 3 and 4 (but not just those) could benefit from proper citations.
-> Your answer - I've added a few more citations to the earlier part of the paper but mostly leave discussion of related work to the section towards the end.
-> Second Round Comment - Yes, there are new references. But I must call your attention to reference 8m which is used in an abusive manner. When there is the need for additional details you simply refer to that work. It is a PhD thesis and is not readily available - it is not the same as a published paper. Yes, you need not (and can not) reproduce entire chapter of a PhD thesis here, but try to give some extra relevant details before sending the reader to that work.

Issue 8
-> First round comment - The code excerpt would benefit from a better explanation. It is hard to extract meaning from them. A description of the syntax would be helpful (or refer the source of where that information can be found).
-> Your answer - I've added a couple of diagrams to help with the cord code, and some (kind of) C code that may help with the BST code. I mention that the syntax is essentially Haskell with ; instead of `seq`, plus additions for the sharing declarations that are described.
-> Second Round Comment - ok

Issue 9
-> First round comment - Section 10 would make more sense if it would follow the more classical approach of "threats to validity". A previous description of the state of the art would also help improving section 10
-> Your answer - I've added more related work, a summary of contributions plus threats to validity.
-> Second Round Comment - It seems that the improvement on this issue was done in section 12. That section 12 is not perfect, but it is an improvement.

Issue 10
First round comment -> - The paper makes use of many concepts specific to this area that were not explained (examples: purity, destructive update, sharing, etc.). Some readers will understand, while others will not and, and this reduces the impact of the paper. Consider adding a section of "related concepts" after the introduction.
-> Your answer - I've not added a separate section but tried to explain a few things in more detail along the way.
-> Second Round Comment - ok

Issue 11
-> First round comment - The reference list is small. I am not suggesting inserting citations just to fill space. What I am saying is that the list of references is small because the paper lack s sections with related work, concepts and state of the art. When you correct those, you will see that the reference list will augment significatively.
-> Your answer - The reference list is longer than is was... See comments on related work. I refer to a couple of PhD theses about the Mars and Disciple languages but am trying to avoid (re)writing a PhD thesis chapter or two.
-> Second Round Comment - It is not an impressive list for a paper, but, ok.

New issue
Issue 13
-> Second Round Comment - The tone of discourse is rather informal. This is noticeable on several aspects. I could mention the specific mention to the reader "you" which is really strange, but the most relevant and noticeable aspects are, perhaps, the arguing concerning the threats to validity, where the author states that papers proposing new languages do not have a threat to validity section and then go on giving examples of how old languages have contributed to newer languages. Well, if this type of paper doesn't need a threats to validity, then, why is there one? Because a reviewers asked for one? This makes no sense. The author is not defending a thesis before a board. The paper should have only what the author feels is needed. Either provide one, or don't. But if you don't provide one and the reader feels there are weak points, the work will not seem very sound. I give you some suggestions of aspects that might be addressed: performance impact, impact on testability, complexity and cognitive load to the programmer, etc. I am not stating you should use any of those - I am saying there is plenty to talk about something that is new. As a reader and a reviewer, I like that section, just not that type of argument.

This time, I am recommending a minor revision. Depending on the other reviewers, it might happen that your paper is accepted right away. If it is not, then, take the opportunity to improving it using this review.

Comments on the Quality of English Language

English must be improved.

The specific comments on this topic are embedded on the comments to the authors.

Author Response

I've (mostly) deleted comments that have been addressed to an acceptable
level. I've also included a more personal note at the end.  Thanks again
for your feedback - I've added an acknowledgement in the paper. Apologies for annoying line breaks.

Note to editor: see Issue 7 concerning reference 8 and the manual
editing of the .bbl file.

> First round comment - The abstract is not conformant to what a reader might expect in a academic paper. Try to focus these three main aspects in the abstract: the topic, the contribution, a brief summary of the methodology, a brief mention to results/conclusions. This way the reader gets an idea about what the paper is.
-> Your answer - Rewritten (this paper was originally written in a deliberately non-academic style and is being transformed into a paper that hopefully meets academic standards while still being relatively accessible to a wider audience).
-> Second Round Comment - The abstract was indeed improved but it is not there yet. It need further improvement.

I've re-written it again.  It now has much more detail about the main
novel features of Pawns. I hope it's still understandable to a wide
audience.

Issue 3
...
-> Second Round Comment - This was improved, but it is not yet solved. You still have vague statements. Some examples: What are those various new language features mentioned at the start f the introduction? Would it make a stronger case to enumerate them right at the star of the motivation statement? What are the "various languages features and compiler analyses" mentioned near the beginning of section 12? What is a "rather old" x86_64 laptop? How recent is a "recent version" of Ububtu Linux? And, for that matter, how much is a "bunch" (in your answer)? The vagueness is not appropriate to a scientific publication, and the informal discourse is also not adequate. This needs to be fixed.

The "various languages features and compiler analyses" is what the paper
describes next (linear types, modes, etc). I've added an explicit
forward reference to make this clear.

Benchmarking details have been added.

The vagueness at the start mostly remains.  I thought it best to try to
summarise *what* styles of programming are supported and *why* they are
important, leaving the "how" (in terms of details of language features)
until later. The abstract does contain more detail now, as does the last
paragraph of the introduction but I didn't feel that listing features
without explaining them would be that helpful. If there is a strong
feeling the the contrary I am happy to add it though.

Issue 7
...
-> Second Round Comment - Yes, there are new references. But I must call your attention to reference 8m which is used in an abusive manner. When there is the need for additional details you simply refer to that work. It is a PhD thesis and is not readily available - it is not the same as a published paper. Yes, you need not (and can not) reproduce entire chapter of a PhD thesis here, but try to give some extra relevant details before sending the reader to that work.

Reference 8 is available online (though not the top hit if you search
for the title).  I had the URL in my bibtex entry but the supplied
bibliography MDPI style does not include URLs for Ph.D. theses. I've
added it to the .bbl file manually but the MDPI editors may want to make
a final decision on this.  I've also included another example where I
refer to [8] in the motivation and added discussion of the Koka language.

Issue 8
-> First round comment - The code excerpt would benefit from a better
explanation. ...
-> Second Round Comment - ok

I've now also added a mention of Haskell do notation, which is very
similar.

New issue
Issue 13
-> Second Round Comment - The tone of discourse is rather informal. This is noticeable on several aspects. I could mention the specific mention to the reader "you" which is really strange, but the most relevant and noticeable aspects are, perhaps, the arguing concerning the threats to validity, where the author states that papers proposing new languages do not have a threat to validity section and then go on giving examples of how old languages have contributed to newer languages. Well, if this type of paper doesn't need a threats to validity, then, why is there one? Because a reviewers asked for one? This makes no sense. The author is not defending a thesis before a board. The paper should have only what the author feels is needed. Either provide one, or don't. But if you don't provide one and the reader feels there are weak points, the work will not seem very sound. I give you some suggestions of aspects that might be addressed: performance impact, impact on testability, complexity and cognitive load to the programmer, etc. I am not stating you should use any of those - I am saying there is plenty to talk about something that is new. As a reader and a reviewer, I like that section, just not that type of argument.

That section was added at the suggestion of more than one reviewer -
it was not in my earlier versions but I was willing to add it. I have
deleted the first sentence and added a little more content. Hopefully it
looks less out of place now. I've reworded sentences with "you".

Additional changes to the paper

There are a some other minor changes including additions to the further work
section (reflecting what I have been doing between paper revisions) and
discussion of Koka in the related work section.

Personal note:

I realise the original style of this paper and the interractions with
me have been unusual for an academic journal.  I'm not sure if you were
saw the original letter I sent to the editor, but the paper was first
written in a non-academic style to be more accessible and I retired as
a paid academic almost eleven years ago due to poor health. Soon after
I was diagnosed with widespread metastatic prostate cancer. Thankfully,
I have survived much longer than doctors expected and continue some
academic work but the pressure to publish papers, waste time applying
for grants, etc is a distant memory.  I've always had reservations
about the way progress in science is judged, the reliance on numbers of
publications and various expectations/norms.  I don't think we always
get the balance between truth and importance right. We want to avoid false
propositions being published but also, publishing propositions that have
no importance or use may be helpful for academic promotions but serves
no wider good (yet I believe I have seen many such papers in my career).
Various conventions have evolved in academic publications, particularly
in experimental sciences, to address the issue of truth.  These include
a precise statement of a hypothesis or research question (what truth
are we addressing), precise description of experiments performed (so
they can be repeated and results validated) and a "threats to validity"
section. There are relatively few conventions addressing how important or
useful or interesting/unexpected the results are.  Perhaps developing
new programming languages should not be considered science, because
it doesn't really uncover truth (though there may be theorems about the
languages we devise), but I think it can be very valuable.