objectionary/eo

Since #8227 a formation can give its receiver a readable name, as in [^s args], and PR #9093 applied it to 214 method receivers in eo-runtime. The rest of the module still reads bare ^. On master (0026883), 90 of the 173 .eo files under eo-runtime/src use it, on about 1,041 lines: 355 bracket heads still open with [^ ...] (local helpers, nested formations, >> formations), and 162 places climb with ^.^. Here is eo-runtime/src/main/eo/directory/listed.eo:76: [^ acc] > gathered if. > @ read.code.eq -1 acc ^.gathered ^.added acc read.name called. > read os.is-windows.if win32.find-next-file ^.opened.code posix.readdir ^.opened.code if. > [^ rest item] > inserted rest.length.eq 0 * item if. ^.ahead item.as-bytes rest.head.as-bytes 0 with. ^.inserted rest.tail item A reader has to count hops to learn what ^.opened or ^.^.^.block points at, which is the exact problem #8227 set out to solve. With half the module on ha

The printer in eo-printer puts an application on several lines even when every argument is a single object, such as a literal or a bare name. For example, eo-runtime/src/main/eo/bytes/as-hex.eo:42 currently reads: | > @ 0 -- It should read: | 0 -- > @ The choice is made in Node.shaped (eo-printer/src/main/java/org/eolang/printer/Node.java:441), which takes the one-line form only when Penalty.points scores it no higher than the vertical one. Penalty charges SPACE (7) for every inner space, plus applied * (applied - 1) for neighbouring non-binding tokens: total += (spaces + applied * (applied - 1)) * this.weight(PenaltyKey.SPACE); With two arguments, this term alone decides the outcome. At indent 2, | 0 -- > @ scores 71 (2 for indent, 15 for @, 12 for symbols, 6 × 7 for spaces), while the three-line form scores 57. One argument still wins: | 0 > @ in directory.eo:41 scores 45 against 47. So any application with two or more simple arguments is always printed verticall

A formation on an inference report page is marked on its opening bracket, so the [ ends up inside the highlighted span. Line 15 of eo-runtime/src/main/eo/number.eo, [] > div /Q.number, is drawn like this: <span class="mark named">[<span class="pop">...</span></span>] > div /Q.number The XMIR puts a formation, and the λ of an atom, at the column of its [. Pieces.directives() in eo-inference/src/main/java/org/eolang/inference/Pieces.java:93 marks whatever Reach.from(column) covers at that column, and Reach.spanned in eo-inference/src/main/java/org/eolang/inference/Reach.java:73 treats a bracket as a one-character glyph: } else { found = 1; } A bracket is punctuation. It names nothing, and a reader hovering over it has no word to connect the popup to. The page already agrees on this elsewhere: keepsTextThatNoObjectClaims in PiecesTest keeps the brackets around a void as plain text. We can't just drop the mark, though. The docblock of Pieces (#8318) counts on it to show an atom that n

Every stage of eo-maven-plugin writes its output into a subdirectory of target/eo/, and each stage picks its own numeric prefix by hand. There's no shared source for these numbers, just a static final String DIR on each stage class: // Parsing.java:53 static final String DIR = "1-parse"; // Pulling.java:29 static final String DIR = "2-pull"; // Linting.java:59 static final String DIR = "3-lint"; // Merging.java:68 static final String DIR = "4-merge"; // MjResolve.java:41 static final String DIR = "4-resolve"; Merging and MjResolve already collide on "4-". It happens not to break anything today only because the two stages run on separate branches of the pipeline and never write into the same target/eo/ at once, but that's an accident of the current wiring, not something the numbering enforces. A few other stages skip the constant entirely and repeat the string as a bare literal instead, so the same name is typed independently in more than one place: "0-raw" in both Parsing.java:206 and

LnApplication.readOuterBinding() at eo-parser/src/main/java/org/eolang/parser/LnApplication.java:121 decides whether an inline :label binding is followed by more chain (and must therefore be rejected under R-6.6.4) using !tokens.atEnd() && tokens.current() == '.'. It only recognizes the plain . dispatch operator and never checks for the fragile ?. operator, which Tokens.dispatchAhead() treats as an equal chain continuation for the identical purpose in readChain() and reversedAhead() (Tokens.java:437-438). This static method is shared by LnMethod.java, LnTextBlock.java, and LnReversed.java, so the gap reaches all four line shapes. Per R-3.5.3a of PARSER_SPEC.md, ?. "parses identically to ." everywhere a dispatch is accepted, and R-6.6.4 forbids an inline binding on any method that isn't the chain's last link. bar.baz:1.qux 5 > z correctly triggers inline binding allowed only on the last method in a chain — this is the fixture that closed #7981. Swap the plain dot for the fragile one,