Perl 5.31.11 puts the next interpreter's semantics within reach

A compact expression can conceal a substantial contract about evaluation. Perl's development series now supports chained comparisons, including a promise that an interior expression is evaluated at most once. April's 5.31.11 snapshot gives module authors another concrete interpreter against which to exercise that contract. Its immediate release notes concentrate on bundled module updates, so understanding the snapshot requires reading the accumulated language documentation as well as the short list of changes.

The 5.31.11 notes report approximately six weeks of development since 5.31.10. The history file records April 28 as its release date. Chained comparisons appeared in the preceding snapshot's notes. They are part of the interpreter available for testing now, rather than a feature first introduced by April's module updates.

A comparison chain does not assign its middle value

The operator reference in 5.31.11 explains a chain using the same precedence group. For ordinary scalar variables, an expression such as the following behaves like two comparisons joined by a short-circuiting conjunction:

if ($low < $value <= $high) {
    print "inside the interval\n";
}

This notation represents an exclusive lower bound and an inclusive upper bound. Its usefulness depends on the shared argument having the expected evaluation behavior. If a subroutine call occupies the middle position, duplicating that call in a manually expanded conjunction can execute it twice. The chain evaluates the argument expression at most once. Arguments that short-circuiting makes unnecessary are not evaluated at all.

An explicit temporary variable is a useful approximation for an ordinary subroutine result, but the documentation says it is not an exact implementation model. The chain performs no assignment to a temporary. That distinction becomes observable with an lvalue subroutine or a tied scalar. Producing the scalar happens at most once, while fetching its value can happen twice, once for each comparison that uses it.

This is the part a superficial syntax demonstration would miss. Evaluation of an expression and retrieval of a scalar's value are separate operations in Perl. Code that attaches behavior to a fetch can therefore observe more than the number of times the argument expression itself runs. A language feature can remove duplicated expressions without promising to remove every repeated interaction with their results.

I appreciate concise Perl when the shorter form preserves a readable account of the operation. Comparison chains meet that preference for ordinary interval checks. The tied-scalar qualification belongs in the explanation because Perl permits behavior that an apparently simple variable access does not reveal.

Precedence still defines the chain

The operator reference explicitly warns that relational comparisons do not chain with equality comparisons. The two groups have different precedence. A reader should not generalize the interval example into a rule that any adjacent comparison operators form one sequence. The equality group has its own chain behavior, while the ordering operators and smartmatch have additional non-associative restrictions.

That matters to compatibility work because a test that merely confirms the common numeric interval case does not describe the full grammar. A module generating expressions has to preserve the intended grouping. The new notation provides a defined convenience within those rules. It does not make precedence disappear or turn Perl source into unrestricted mathematical notation.

Bundled modules remain part of the interpreter under test

April's notes list updates to modules including B::Deparse, charnames, and Unicode::UCD. The deparser moves from 1.52 to 1.53, while charnames moves from 1.46 to 1.47. These are concrete changes to the distribution. The notes do not provide a separate behavioral explanation for each version increment, so a version list alone cannot justify claiming a particular new capability for every module.

The bundled charnames documentation supplies useful context for testing Unicode name handling. It distinguishes compile-time name escapes from runtime lookup. A \N{...} escape cannot interpolate a variable to choose its name. charnames::string_vianame provides runtime lookup and returns a string, including for a named sequence. charnames::vianame ordinarily returns a code point and cannot represent a sequence of multiple characters.

Those are existing documented distinctions to preserve, not claims that April invented the interfaces. The same reference explains that unknown runtime names return undef, while an unknown name in the compile-time escape is a syntax error. Moving name selection between those interfaces therefore changes when and how failure appears. Matching the visible character on the successful path is insufficient to show that a refactoring retains the same contract.

My interest in a development snapshot is this opportunity to compare precise behavior before treating a new interpreter as routine. Here the relevant work includes expression evaluation and the bundled modules that expose character data. The snapshot provides a dated implementation and its own documentation, allowing module maintainers to distinguish a changed result from a changed assumption about how that result is obtained.