[REVIEW]: MutableArithmetics: An API for mutable operations

[whedon]

Submitting author: !--author-handle-->@blegat<!--end-author-handle-- (Benoît Legat) Repository: https://github.com/jump-dev/MutableArithmetics.jl/ Branch with paper.md (empty if default branch): Version: v1.4.3 Editor: !--editor-->@lucaferranti<!--end-editor-- Reviewers: @schillic, @ksil Archive: 10.5281/zenodo.10985724

Status

Status badge code:

HTML: <a href="https://proceedings.juliacon.org/papers/7768893900f2b6be4bac7e16b843bd01"><img src="https://proceedings.juliacon.org/papers/7768893900f2b6be4bac7e16b843bd01/status.svg"></a>
Markdown: [![status](https://proceedings.juliacon.org/papers/7768893900f2b6be4bac7e16b843bd01/status.svg)](https://proceedings.juliacon.org/papers/7768893900f2b6be4bac7e16b843bd01)

Reviewers and authors:

Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

Reviewer instructions & questions

@ksil, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:

1. Make sure you're logged in to your GitHub account
2. Be sure to accept the invite at this URL: https://github.com/openjournals/joss-reviews/invitations

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @ranjanan know.

✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨

Review checklist for @ksil

Conflict of interest

• [x] As the reviewer I confirm that I have read the JuliaCon conflict of interest policy and that there are no conflicts of interest for me to review this work.

Code of Conduct

• [x] I confirm that I read and will adhere to the JuliaCon code of conduct.

General checks

• [x] Repository: Is the source code for this software available at the repository url?
• [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• [x] Authorship: Has the submitting author (@blegat) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

• [x] Installation: Does installation proceed as outlined in the documentation?
• [x] Functionality: Have the functional claims of the software been confirmed?
• [x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• [x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• [x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• [x] Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
• [x] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Paper format

• [x] Authors: Does the paper.tex file include a list of authors with their affiliations?
• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?
• [x] Page limit: Is the page limit for full papers respected by the submitted document?

Content

• [x] Context: is the scientific context motivating the work correctly presented?
• [x] Methodology: is the approach taken in the work justified, presented with enough details and reference to reproduce it?
• [x] Results: are the results presented and compared to approaches with similar goals?

Review checklist for @schillic

Conflict of interest

• [x] As the reviewer I confirm that I have read the JuliaCon conflict of interest policy and that there are no conflicts of interest for me to review this work.

Code of Conduct

• [x] I confirm that I read and will adhere to the JuliaCon code of conduct.

General checks

• [x] Repository: Is the source code for this software available at the repository url?
• [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• [x] Authorship: Has the submitting author (@blegat) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

• [x] Installation: Does installation proceed as outlined in the documentation?
• [x] Functionality: Have the functional claims of the software been confirmed?
• [x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• [x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• [x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• [x] Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
• [x] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Paper format

• [x] Authors: Does the paper.tex file include a list of authors with their affiliations?
• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?
• [x] Page limit: Is the page limit for full papers respected by the submitted document?

Content

• [x] Context: is the scientific context motivating the work correctly presented?
• [x] Methodology: is the approach taken in the work justified, presented with enough details and reference to reproduce it?
• [x] Results: are the results presented and compared to approaches with similar goals?

[whedon]

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @ksil it looks like you're currently assigned to review this paper :tada:.

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

:star: Important :star:

If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this (https://github.com/JuliaCon/proceedings-review) repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿

To fix this do the following two things:

1. Set yourself as 'Not watching' https://github.com/JuliaCon/proceedings-review:

2. You may also like to change your default settings for this watching repositories in your GitHub profile here: https://github.com/settings/notifications

For a list of things I can do to help you, just type:

@whedon commands

For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:

@whedon generate pdf

[whedon]

Failed to discover a Statement of need section in paper

[whedon]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1137/141000671 is OK
- 10.1287/opre.38.5.911 is OK
- 10.1137/15M1020575 is OK
- 10.5281/zenodo.5083796 is OK
- 10.1145/3087604.3087611 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

Wordcount for paper.tex is 2993

[whedon]

Software report (experimental):

github.com/AlDanial/cloc v 1.88  T=0.07 s (676.2 files/s, 229805.8 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
TeX                              9            274            305          10672
Julia                           31            490            370           4392
Markdown                         2             42              0            177
YAML                             4              0              3             99
TOML                             3             26              1             85
Ruby                             1              8              4             45
-------------------------------------------------------------------------------
SUM:                            50            840            683          15470
-------------------------------------------------------------------------------

Statistical information for the repository 'b56fd335df768627fe3e1519' was
gathered on 2021/10/16.
The following historical commit information, by author, was found:

Author                     Commits    Insertions      Deletions    % of changes
Benoît Legat                     1            57              0          100.00

Below are the number of rows from each author that have survived and are still
intact in the current revision:

Author                     Rows      Stability          Age       % in comments
Benoît Legat                 57          100.0          0.0                7.02

[whedon]

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

[ranjanan]

@whedon commands

[whedon]

Here are some things you can ask me to do:

# List all of Whedon's capabilities
@whedon commands

# Assign a GitHub user as the sole reviewer of this submission
@whedon assign @username as reviewer

# Add a GitHub user to the reviewers of this submission
@whedon add @username as reviewer

# Re-invite a reviewer (if they can't update checklists)
@whedon re-invite @username as reviewer

# Remove a GitHub user from the reviewers of this submission
@whedon remove @username as reviewer

# List of editor GitHub usernames
@whedon list editors

# List of reviewers together with programming language preferences and domain expertise
@whedon list reviewers

# Change editorial assignment
@whedon assign @username as editor

# Set the software archive DOI at the top of the issue e.g.
@whedon set 10.0000/zenodo.00000 as archive

# Set the software version at the top of the issue e.g.
@whedon set v1.0.1 as version

# Open the review issue
@whedon start review

EDITORIAL TASKS

# All commands can be run on a non-default branch, to do this pass a custom 
# branch name by following the command with `from branch custom-branch-name`.
# For example:

# Compile the paper
@whedon generate pdf

# Compile the paper from alternative branch
@whedon generate pdf from branch custom-branch-name

# Remind an author or reviewer to return to a review after a
# certain period of time (supported units days and weeks)
@whedon remind @reviewer in 2 weeks

# Ask Whedon to do a dry run of accepting the paper and depositing with Crossref
@whedon recommend-accept

# Ask Whedon to check the references for missing DOIs
@whedon check references

# Ask Whedon to check repository statistics for the submitted software
@whedon check repository

EiC TASKS

# Invite an editor to edit a submission (sending them an email)
@whedon invite @editor as editor

# Reject a paper
@whedon reject

# Withdraw a paper
@whedon withdraw

# Ask Whedon to actually accept the paper and deposit with Crossref
@whedon accept deposit=true

[ranjanan]

@whedon list reviewers

[whedon]

Here's the current list of reviewers: http://bit.ly/2V9GSFq

[ranjanan]

@whedon add @tkf as reviewer

[whedon]

OK, @tkf is now a reviewer

[ranjanan]

@whedon re-invite @tkf as reviewer

[whedon]

@tkf already has access.

[ranjanan]

@tkf I've added a checklist for you as well.

[ksil]

I recommend accepting the paper with minor modifications. Here are my comments:

• There are some minor grammar issues (e.g., "This is examples encapsulates..." on page 1, "As the result of promote_operation..." on page 3, "is a the core of many operation" on page 3)
• Could you clarify a bit more what you mean by "in case the trait mutability is optimized out" on page 3?
• The sentence "Indeed, as the functions op and operate! are strictly more specific...." is confusing and could be improved.
• The variable buf on page 3 after the sentence "Then, the matrix multiplication can create..." is used before it is defined later. I would define buf earlier so that this line of code here is clearer.
• I would be a little more precise about the word "layers" when you say "Mutable objects may have multiple layers." Perhaps "a hierarchy of mutable members" or something along those lines?

[ksil]

Otherwise, it's a really interesting piece of work! I'm looking forward to using it myself.

[blegat]

Thank you for the review, I have updated the paper using your suggestions.

[blegat]

@whedon generate pdf

[whedon]

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

[ksil]

"This examples encapsulates" on page 1 should be "This example encapsulates", and "is a the core" should be "is at the core" on page 3. Otherwise, with those changes, everything looks good to me @ranjanan

[blegat]

Thanks your for noticing this and sorry I missed these in your comments, I just fixed these two typos.

[blegat]

@whedon generate pdf

[whedon]

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

[ranjanan]

@tkf a reminder to submit your review.

[ranjanan]

@tkf another reminder to submit your review

[ranjanan]

@tkf

[ranjanan]

@tkf bump

[ranjanan]

@tkf

[ranjanan]

@tkf

[ranjanan]

@whedon remove @tkf as reviewer

[whedon]

OK, @tkf is no longer a reviewer

[ranjanan]

@whedon add @aviatesk as reviewer

[whedon]

OK, @aviatesk is now a reviewer

[ranjanan]

@aviatesk just a reminder for this review.

[matbesancon]

@whedon assign @lucaferranti as editor

[lucaferranti]

@blegat I'll be the new editor for this submission.

@aviatesk :wave: , are you still willing to review this?

[lucaferranti]

@schillic agreed to review this submission.

Christian, you can find the review process guidelines here, if you have any questions do let me know.

[lucaferranti]

@whedon help

[whedon]

I'm sorry human, I don't understand that. You can see what commands I support by typing:

@whedon commands

[lucaferranti]

@whedon commands

[whedon]

Here are some things you can ask me to do:

# List Whedon's capabilities
@whedon commands

# List of editor GitHub usernames
@whedon list editors

# List of reviewers together with programming language preferences and domain expertise
@whedon list reviewers

EDITORIAL TASKS

# Compile the paper
@whedon generate pdf

# Compile the paper from alternative branch
@whedon generate pdf from branch custom-branch-name

# Ask Whedon to check the references for missing DOIs
@whedon check references

# Ask Whedon to check repository statistics for the submitted software
@whedon check repository

[lucaferranti]

@whedon assign @schillic as reviewer

[whedon]

I'm sorry @lucaferranti, I'm afraid I can't do that. That's something only editors are allowed to do.

[lucaferranti]

@whedon generate pdf

[whedon]

PDF failed to compile for issue #93 with the following error:

 Latexmk: This is Latexmk, John Collins, 17 Jan. 2018, version: 4.55.
Rule 'pdflatex': Rules & subrules not known to be previously run:
   pdflatex
Rule 'pdflatex': The following rules & subrules became out-of-date:
      'pdflatex'
------------
Run number 1 of rule 'pdflatex'
------------
------------
Running 'pdflatex  -recorder  "paper.tex"'
------------
Failure to make 'paper.pdf'
Collected error summary (may duplicate other messages):
  pdflatex: Command for 'pdflatex' gave return code 1
      Refer to 'paper.log' for details
Looks like we failed to compile the PDF

[lucaferranti]

@whedon assign lucaferranti as editor

[whedon]

I'm sorry @lucaferranti, I'm afraid I can't do that. That's something only editors are allowed to do.

[lucaferranti]

@whedon remove aviatesk as reviewer

[whedon]

I'm sorry @lucaferranti, I'm afraid I can't do that. That's something only editors are allowed to do.