refactor: @immut/array.make and @immut/array.makei

[illusory0x0]

avoid use closure

And this implementation will be a bit simpler than the previous new_by_leaves, and can also be reused by from_iter

• [Performance] @immut/array::from_iter #1583

[coveralls]

Pull Request Test Coverage Report for Build 5695

Details

• 21 of 22 (95.45%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.007%) to 92.635%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
immut/array/array.mbt	21	22	95.45%

Totals
Change from base Build 5689:	-0.007%
Covered Lines:	6037
Relevant Lines:	6517

---

💛 - Coveralls

[peter-jerry-ye]

Is the alias here expected (using Array::make)? If yes, should it apply to the second arr too?

let arr : Array[FixedArray[A]] = Array::make(quot + 1, FixedArray::make(branching_factor, value))
arr[quot] = FixedArray::make(rem, value)

[jialunzhang-psu]

I think there is another optimization that can be done: since the leaves won't get modified by themselves while having the same content, we can just do

    let leaf = FixedArray::make(branching_factor, value)
    let arr : Array[FixedArray[A]] = Array::make(quot + 1, leaf)

[peter-jerry-ye-code-review]

‼️ This code review is generated by a bot. Please verify the content before trusting it.

The pull request aims to simplify the implementation of make and makei by avoiding closures and reusing the from_leaves function. The changes primarily involve refactoring the code to remove the new_by_leaves function and replacing it with a more direct approach. Here are the key observations and feedback:

💡 [Improvement in code clarity and simplicity]

• Category: Maintainability
• Code Snippet: Lines 25-47 (make function), Lines 50-72 (makei function)
• Recommendation: The new implementation is more straightforward and avoids the use of closures, making the code easier to understand and maintain.
• Reasoning: By breaking down the problem into simpler steps and avoiding closures, the code becomes more explicit. This reduces the cognitive load on developers and makes the codebase easier to maintain and debug.

⚠️ [Deprecated function `check_fixedarray_eq`]

• Category: Correctness
• Code Snippet: Lines 132-140 (check_fixedarray_eq function)
• Recommendation: If check_fixedarray_eq is deprecated or no longer needed, it should be removed entirely rather than commented out.
• Reasoning: Commented-out code can clutter the codebase and confuse developers. If the function is no longer used, it should be deleted to keep the codebase clean and maintainable.

💡 [Improvement in function reusability]

• Category: Maintainability
• Code Snippet: Lines 362-389 (from_leaves function)
• Recommendation: The from_leaves function is now reusable and more generic, which is a positive change.
• Reasoning: By making from_leaves a standalone function that can be used by both make and makei, the code becomes more modular and reusable. This reduces code duplication and promotes better code organization.

Overall, the changes improve the code's readability, maintainability, and reusability. The only significant concern is the commented-out check_fixedarray_eq function, which should be removed if it is no longer needed.

[jialunzhang-psu]

I think there is another optimization that can be done: since the leaves won't get modified by themselves while having the same content, we can just do

    let leaf = FixedArray::make(branching_factor, value)
    let arr : Array[FixedArray[A]] = Array::make(quot + 1, leaf)

[jialunzhang-psu]

To my understanding, given a list of leaves, this function constructs the tree top-down. It causes a from_leaves call for every tree node. A more efficient way is to do it bottom-up, building the tree layer by layer. But it is just a suggestion for improvement, it is okay to leave it this way. I can update it later.