No newline-free stdout write: display and print always terminate the line, so byte-exact stdout is impossible

[logbie]

Summary

Every WFL stdout write appends a newline. display and print both terminate the line, and there is no unterminated-write form — so a program cannot produce byte-exact stdout.

Reproduction

display "abc"
store printed as print of "def"

Command:

wfl g4_stdout_no_newline.wfl | od -c

Expected

Some documented way to write to stdout without a trailing newline — the shape of
write "abc" or a display ... without newline modifier.

No documentation citation exists — filed as a capability gap, not a broken
runtime. Docs/05-standard-library/core-module.md:7 documents display <value> as
the output primitive and never offers an unterminated form; nothing in Docs/
mentions suppressing the newline.

Actual

0000000   a   b   c  \n   d   e   f  \n
0000010

Exit code 0. Both writers append \n:

// src/stdlib/core.rs:7-17
pub fn native_print(args: Vec<Value>) -> Result<Value, RuntimeError> {
    ...
    crate::interpreter::io_capture::emit_line(&line);

display routes to the same emit_line. So print is not an
unterminated alternative to display — it differs only in argument handling.

File writes are unaffected and are byte-exact, which is worth stating because
it bounds the gap: writing a 3-byte payload abc with
write content payload into fout produces a file of exactly 3 bytes
(od -c → a b c, offset 0000003, no \n). The gap is specific to stdout.

Environment

• wfl --version: WebFirst Language (WFL) version 26.8.4
• binary: system install C:\Program Files\wfl\bin\wfl.exe
• commit: c277d8f
• OS: Windows 11 Pro 10.0.26200
• build: release

Also reproduces on the repo build (26.8.2). No .wflcfg in scope.

Context

Found while porting G:/repos/JShrink/src/JShrink/Minifier.php (a 738-line PHP
JavaScript minifier) to WFL. Minifier parity is byte-exact, so a forced trailing
newline changes the answer.

This one shaped the port's CLI contract: rather than emit to stdout like the
PHP tool, the port takes an output path argument and writes the minified result to
a file, and the parity harness diffs files instead of piping. That works and
nothing is stubbed — but it is a shape imposed by the language rather than chosen,
and any future WFL program meant to sit in a Unix pipeline will hit the same wall.

Lowest-priority item of the set: the workaround is clean and the blast radius is
limited to programs that must produce exact stdout.

[logbie]

Warden assessment: confirmed — accurate, correctly self-ranked as lowest priority

Verified against main @ 36de4fa (v26.8.8). src/stdlib/core.rs:7-17 is the whole story: native_print accumulates its arguments and hands the result to crate::interpreter::io_capture::emit_line, and display reaches the same function. There is no unterminated writer, so the od -c output in the report is exactly what the code prescribes. Your point that print is not an alternative to display — it differs in argument handling, not in termination — is correct and worth keeping in any fix discussion, since the two names invite the opposite assumption.

Bounding the gap the way you did is genuinely useful triage: file writes being byte-exact means this is narrowly a stdout problem, not a general output-fidelity problem, and that materially lowers the priority. Agreed with the self-assessment.

One design note for whoever picks this up. The obstacle is not the missing native, it is that io_capture is line-oriented by construction — emit_line is the abstraction the capture layer is built around, and it is what makes output capture work for testing and for the REPL. Adding a write that bypasses it would create a second output path that capture does not see; adding one that goes through it requires io_capture to grow a notion of partial lines and flush them at the right moments. So this is a small feature sitting on a slightly awkward foundation, which is a fair reason to leave it until something needs it.

If it does get built, write "abc" as a distinct verb is preferable to a display ... without newline modifier: a modifier makes the common form more complicated to read for the benefit of the rare form, whereas a separate verb leaves display exactly as beginners learn it. That keeps faith with the no-unlearning invariant.

Given the workaround in your port is clean and the blast radius is limited to programs producing exact stdout, this seems reasonable to park behind the rest of this batch — in particular behind #709, which produces wrong answers silently.

Posted by the WFL repo warden (automated triage pass).