Corinna considers a smaller first implementation
Curtis Poe reports council interest in a staged Corinna implementation. A limited first deliverable raises questions about compatibility and the boundary between a proposal and a supported language feature.
Corinna may enter the Perl core through a smaller first implementation than the full proposal. In his December 10 account of a meeting with the Perl Steering Council, Curtis Poe says the council is receptive to the project and that implementation will likely happen in stages. He has supplied a document describing a very small viable subset. He explicitly makes no promise about delivery and offers only the possibility of an RFC by Christmas.
That distinction between interest and commitment is the useful starting point. A discussion with the council can establish a direction without deciding an implementation schedule. A document describing possible initial scope is not a released language feature. The practical question is how much of an object system has to exist before real use can provide useful evidence about its design.
I value Perl most for concise text work, so native object syntax does not need to change every program I write to be worth examining. Its value depends on whether it makes larger Perl programs easier to understand. A staged implementation offers a way to examine that question without pretending the entire proposed design is already settled.
A subset still defines expectations
Poe describes the proposed first subset as mostly forward-compatible with newer versions of Corinna. The qualifier matters. It identifies compatibility as a design goal while leaving open the possibility that some early choices will change. A reader should not silently replace that statement with a guarantee that all source using an initial implementation will survive unchanged.
A small implementation can limit the number of decisions made at once. It also has to choose enough behaviour to let a program use it coherently. Omitting a capability does not remove every decision associated with it. An initial object model may constrain what can be added later, so a subset needs an explanation of which choices are deliberate foundations and which remain provisional.
This is an engineering interpretation of the staged approach, not a claim that the announcement lists the subset's exact contents. It does not. The public message says that Poe has provided a document and that discussion will continue about what can be achieved. It supplies neither a finalized syntax specification nor a patch ready for an interpreter release.
That makes a code example misleading here if it looks like syntax a reader can already enable in stock Perl. The event is a design and delivery discussion. A precise explanation can describe the proposed process without presenting hypothetical class declarations as a supported interface. The lack of an implementation example follows from what the source establishes.
Council support and project design have different roles
The governance document published in November 2020 defines broad council authority over language development and the process producing interpreter releases. It allows the council to establish how proposals are discussed and decided. It also permits delegation. Those provisions explain why a project proposing native syntax needs a path through core development even when much of its design work happens elsewhere.
The same rules prefer consensus and general procedures over repeated case-by-case rulings. That matters to interpreting a receptive meeting. Support for examining Corinna can begin a process in which implementation details receive review. It does not establish that every design choice has received final approval. The council's institutional role and the proposal authors' design work must still meet through a concrete contribution process.
The governing mandate includes both evolution and stability of the language. A smaller first delivery puts those responsibilities into the same decision. New functionality needs enough use to expose design problems, while shipped behaviour creates expectations for users. The governance rules identify the people responsible for decisions, but cannot supply technical answers that the implementation has not yet established.
This is why the suggested RFC is significant even though it remains unpromised. A public proposal can identify the intended initial scope and the compatibility claims attached to it. Reviewers can then discuss a particular contract instead of reacting to the entire ambition of a new object system. That would make disagreements more concrete without requiring the first RFC to settle every eventual capability.
Existing experiments show how status can be communicated
The feature documentation shipped with Perl 5.35.5 provides an existing mechanism for explicitly selecting experimental language behaviour. Its try documentation says the implementation may change or be removed and names the warning used to report feature use. That is an example of communicating an experiment's status in source, not evidence that Corinna has adopted the same exact mechanism.
An eventual Corinna proposal will need its own clear statement about status. A small implementation can be useful while incomplete, but users need to know which compatibility expectations are appropriate. A warning category alone cannot explain every design boundary. Documentation has to identify what the implementation promises and what remains subject to revision.
The distinction also affects examples. A sample intended to demonstrate a proposed model should say that it is a proposal. A sample for a released interpreter should name the version and declarations it requires. Without those qualifications, a reader can reasonably mistake a design discussion for an available feature. That would create expectations beyond anything Poe announces today.
I prefer an initial scope that can be described precisely enough for that kind of review. A large proposed feature list is difficult to assess when none of its parts has implementation feedback. A smaller deliverable can make the first compatibility decisions explicit, provided its documentation does not turn an intention into a guarantee.
The immediate next step is still discussion
Poe reports interest from people asking the council about Corinna, but his announcement does not quantify demand or claim an agreed release target. It describes a productive meeting and an initial document. The statement about a possible RFC is expressly conditional. Treating Christmas as a deadline would remove a qualification the author takes care to repeat.
The useful outcome on December 10 is therefore a more limited delivery direction and an active conversation about it. Future proposals can specify exactly what the first implementation contains. For now, the public commitment is to continue discussing what can be achieved, with a mostly compatible subset as the proposed starting point.