The ticket PUP-4193 is a bout pattern matching support in the Puppet Language. At first the ability to use a lambda as a case option was added to Puppet, but later (in the same ticket) reverted for the purpose of first being described and discussed.

This is a request to get an identifier for this work.

XPP is a file format that allows puppet manifests to be pre-parsed and pre-validated before being used at runtime to compile a catalog. XPP also serves as an interchange format between different platforms; for example a C++ implementation of the parser, and the Ruby runtime.

I would like to request a new ARM identifier so I can propose a new level of scope for nodes, to be able to have a sane fix for #1372

There is currently no way to control the iteration in the Puppet Language as there are no mechanisms to cause an early exit, or skipping an iteration from an iterative functions lambda.

The idea is to specify the semantics for two functions: break(val = undef), and next(val=undef) that enables control of iteration.

Who are they? (PuppetCore?)
Committer elections?

There needs to be legal information somewhere. License, Copyrights, etc.
When contributing what have you signed up for / what is it you are giving away.
Who may use the ideas, and for what purpose, etc.

Currently, resources are instantiated in a lazy fashion when compiling a catalog. That is, a resource expression evaluation is (almost) partially evaluated (it binds arguments to parameters, but not efault values). The partially evaluated instantiation is queuedand the queue is processed in order when there is no more directly evaluated logic to evaluate.

This behavior makes it very difficult for users to reason about "evaluation order". The reasons for keeping the behavior are:

• the amount of breakage a change would cause
• very deep loops constructed with resource instantiation could overflow the stack (avoided by queuing)

The reasons for changing this are:

• Makes reasoning about evaluation order much easier (resources behave as non parameterized classes do today)
• There is no difference between a parameterized class (done as a resource) and a class include
• Enables clean up of logic that now jumps through hoops to ensure logic is evaluated after the body of a given resource.
• Removes one requirement (to keep the same order of evaluation) when refactoring catalog building

We need to describe how someone is supposed to comment.

• To arm-0 and arm-1
• To other ARMs

Suggest:

For arm 0 and 1, either do a PR with a fix (and comment there), or log an issue (a reference URL to the location in text is always helpful).

For other ARMs, the comments should really be directed to the repo where the work is being done. That repo should have an issue tracker turned on, and have labels with arm name-number (e.g. I would have arm-2-iteration as a label in my fork).

Modules could leverage their given namespace to distinguish on one publisher's module from another and be imported based on that namespace.

Example use cases include separating the postgresql module used by PE from a general-use module, or extending a given foo-mysql module with bar-mysql that adds defines, classes, or types without conflicting over the 'mysql' module name.

If we want to keep track of endorsements/approvals we could use signed tags. It may be difficult when the master project contains all ARMs -not investigated. An alternative is also to have ARMs ultimate approval/endorsement be controlled by a redmine issue.

For Windows PowerShell Desired State Configuration that is.

As stated in the spec

Why should this work be done? What are its benefits? Who's asking for it? How does it compare to the competition, if any?

I'd really like to see some answers to these questions. This spec seems like a extremely complex solution to a problem that doesn't exist.

a user may wish long for the perceived "simpler times"

Yeah...

[yanked from arm-0]

• Startdate
• Template/Pep version
• Creation date (is perhaps already defined by looking at git data)
• Author / Organization (is perhaps already defined by using git)
• Associated issues this ARM will address (fix)

It is good to be able to see the state and version of the various proposals.

Propose that the README.md has the list of ARMs in a table where version and state is displayed.

We need suitable states - propose that the version indicates the state (where X indicates number > 0):

• 0.0.0 - 0.0.X, initial (nothing there yet, please do not start commenting yet)
• X.0.X - X.X.X draft (being worked on, comments welcome, but not ready for evaluation/review/decision)
• X.0.0, review (open for comments/review)

Table also needs two dates:

• when version was published (this is kind of hard to figure out; you need to go to the ARM and look at all of the files)
• when the next draft/review version is planned to be due (useful for someone that is interested in a proposal - engage now, or wait for the next version).

The intent is that someone that publishes a new version updates the master index in the same PR.

"Bug" does not seem to fit, the other are ok although "Enhancement" is kind of confusing - enhance what. Suggest we use something more suitable to text and process; such as "wrong", "unclear", "missing"

Need one that represents "Please give me an ARM-number". Suggest "arm-request" (to get arm number, and similar issues).

In PUP-4193, the value of having an "anonymous"/"ignored" parameter named _ is discussed. The intended use is as a variable name. When assigned, it is simply skipped. This is useful in a lambda where the function feeds values into the lambda that are not going to be used, and (as discussed in PUP-4193) as a wildcard in pattern matching.

The work is to compare how variables like this is used in other languages and how this can be applied/made useful in the Puppet Language.

Please issue an official PRFC number to document the evolution of @masterzen's work into shipped code.

(Spoiler alert, it will be PRFC-22)

The current index.md of ARM-1 states that it is templates, but doesn't give clear steps on how to use them. The text should be updated to indicate the expected way of using the templates that it provides.