Skip to content

Conversation

@uchitsa
Copy link
Member

@uchitsa uchitsa commented Dec 21, 2025

Summary by CodeRabbit

  • New Features
    • Introduced a new sprintf function supporting %s (string), %d (integer), and %f (floating-point) format specifiers.
    • Added comprehensive test coverage demonstrating multiple formatting scenarios.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 21, 2025

Walkthrough

Introduces a new pure EO implementation of sprintf that parses format strings and generates formatted output. The object handles format specifiers (%s, %d, %f), literal %% escapes, and missing arguments with defaults. Includes comprehensive test cases demonstrating various formatting scenarios.

Changes

Cohort / File(s) Summary
sprintf implementation and tests
eo-runtime/src/main/eo/org/eolang/sprintf.eo
New file adding pure EO sprintf object with format string parsing, support for %s (string), %d (integer), and %f (float) specifiers, argument handling with defaults, and test_sprintf fixture exercising four formatting scenarios with stdout output

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

  • Format string iteration and state machine logic with nested conditionals for character dispatch and specifier handling
  • Multiple format specifier implementations (%s, %d, %f) with precision handling for floats
  • Argument consumption and default value logic when arguments are insufficient
  • Edge cases: literal %%, missing arguments, format specifier validation
  • Test coverage verification across all four test scenarios

Suggested reviewers

  • maxonfjvipon
  • yegor256

Poem

🐰 A rabbit hops through format strings with glee,
Parsing %s, %d, %f—what shall we see?
sprintf now nestled in EO's domain,
Arguments dancing through loop and refrain,
Output flows cleanly to stdout's delight! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)
Check name Status Explanation Resolution
Title check ❓ Inconclusive The title 'sprintf.eo' is vague and only mentions a filename without conveying the actual purpose or main change being introduced. Revise the title to clearly describe the change, such as 'Implement sprintf function in pure EO' or 'Add sprintf implementation to EO runtime'.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@uchitsa uchitsa marked this pull request as draft December 21, 2025 23:22
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

🧹 Nitpick comments (1)
eo-runtime/src/main/eo/org/eolang/sprintf.eo (1)

96-130: Test object should be in a separate test file.

The test_sprintf object is co-located with the main implementation. Following standard practice, test code should reside in a separate test file (e.g., under a test directory) to keep production code clean and allow independent test execution.

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3739947 and a67317c.

📒 Files selected for processing (1)
  • eo-runtime/src/main/eo/org/eolang/sprintf.eo (1 hunks)
🔇 Additional comments (2)
eo-runtime/src/main/eo/org/eolang/sprintf.eo (2)

114-130: The code is correct; stdout accepts single arguments.

Each stdout call in lines 114-130 is a separate statement within the seq block. The stdout object accepts a single [text] parameter, not multiple arguments. The indented formatting creates a sequence of distinct stdout calls, not multiple arguments to one call. No changes needed.


1-1: Remove or clarify the suspicious alias that conflicts with the local sprintf definition.

This file defines a complete sprintf implementation in the org.eolang package (line 10), yet it imports an alias to org.eolang.tt.sprintf (line 1). This creates ambiguity about which sprintf is actually used. Additionally, based on the codebase structure, the correct import should be org.eolang.txt.sprintf (not tt), as sprintf was moved from the root to the txt folder. Either remove the alias since this file defines its own implementation, or clarify why the external reference is needed.

Comment on lines +10 to +12
[] > sprintf
format > fmt
args > args
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

Critical: sprintf object lacks parameter definitions.

The object is defined with [] > sprintf (no parameters), but lines 11-12 reference format and args as if they were passed in. In EO, parameters should be declared in the brackets. This will cause undefined reference errors.

🔎 Proposed fix to add parameters
-[] > sprintf
-  format > fmt
-  args > args
+[format args] > sprintf
+  format > fmt
+  args > args
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
[] > sprintf
format > fmt
args > args
[format args] > sprintf
format > fmt
args > args
🤖 Prompt for AI Agents
In eo-runtime/src/main/eo/org/eolang/sprintf.eo around lines 10 to 12, the
object is declared with no parameters ([] > sprintf) but then uses `format` and
`args`; update the object header to declare those parameters (e.g., include
`format` and `args` inside the brackets) so `format > fmt` and `args > args`
reference defined parameters; ensure the parameter names match the uses in the
body and adjust any naming consistency (fmt vs format) if needed.

Comment on lines +21 to +26
while. > @
i.lt (fmt.length)
[i] > @
if. > current_char
fmt.at i
current_char
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

Critical: Self-referential conditional and parameter shadowing.

Two issues here:

  1. Line 23: The while loop parameter [i] shadows the outer memory > i object, which will break the loop logic since the inner i won't refer to the mutable counter.
  2. Lines 24-26: The if. statement references current_char in its own definition, which is self-referential and invalid.

The correct structure should extract the character first, then use it:

fmt.at i > current_char
if.
  current_char.eq "%"
  ...
🤖 Prompt for AI Agents
In eo-runtime/src/main/eo/org/eolang/sprintf.eo around lines 21 to 26, the inner
parameter `[i]` in the while block shadows the outer mutable `memory > i`
counter and the `if.` uses `current_char` in its own definition
(self-referential). Remove the inner `[i]` parameter so the while body mutates
the outer `i`, first evaluate the character with `fmt.at i > current_char`, then
call `if.` using a proper comparison like `current_char.eq "%"` (or other
predicate) instead of referencing `current_char` inside the `if.` definition.

Comment on lines +37 to +41
seq > @
output.write > @
output.concat "%"
i.write > @
i.add 2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Multiple > @ decorations within seq block may cause unexpected behavior.

Within the seq block, multiple expressions are decorated with > @. In EO, > @ indicates the "phi" attribute (return value). Having multiple > @ decorations in sequence is ambiguous—typically only the last should be the return value, and intermediate steps should not be decorated.

The pattern repeats throughout lines 44-55, 58-69, 72-83, and 84-88. Consider removing > @ from intermediate statements within seq blocks.

🤖 Prompt for AI Agents
In eo-runtime/src/main/eo/org/eolang/sprintf.eo around lines 37-41, multiple
expressions inside the seq block are annotated with "> @" which makes the return
(phi) ambiguous; remove the "> @" decoration from intermediate statements (e.g.,
output.write and i.write) so only the final intended expression in each seq has
"> @". Apply the same change to the other reported ranges (44-55, 58-69, 72-83,
84-88), leaving a single "> @" on the last expression of each seq and deleting
it from preceding statements.

Comment on lines +105 to +108
memory > result3
sprintf
"Pi: %.2f"
(3.14159 0.0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

Float precision specifier %.2f is not implemented.

The test uses format string "Pi: %.2f" which includes a precision specifier (.2), but the implementation at lines 70-83 only handles bare %f. The code will fail to match next_char.eq "f" because next_char will be . (the character after %), not f.

Either:

  1. Update the test to use %f without precision: "Pi: %f"
  2. Or implement precision parsing in the format specifier handling
🤖 Prompt for AI Agents
In eo-runtime/src/main/eo/org/eolang/sprintf.eo around lines 105-108, the format
string "Pi: %.2f" uses a precision specifier (".2") but the current parser only
expects a bare "%f" so it will see '.' as the next_char and fail; fix by either
(A) updating the test to use "Pi: %f" (remove the precision) OR (B) implement
precision parsing: after consuming '%' check for an optional '.' followed by one
or more digit chars, parse that integer as precision, then continue to match the
type char 'f' and format the float with the parsed precision when constructing
the output.

@github-actions
Copy link
Contributor

🚀 Performance Analysis

All benchmarks are within the acceptable range. No critical degradation detected (threshold is 100%). Please refer to the detailed report for more information.

Click to see the detailed report
Test Base Score PR Score Change % Change Unit Mode
benchmarks.XmirBench.xmirToEO 159.500 174.315 14.815 9.29% ms/op Average Time

⚠️ Performance loss: benchmarks.XmirBench.xmirToEO is slower by 14.815 ms/op (9.29%)

@uchitsa uchitsa closed this Jan 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant