Parameters: Valid Use Context?

[tajmone]

Which are the valid contexts in which parameter can be expanded, and the invalid ones (if any)?

• Inside other [const definitions?
• Date values?
• etc.

I need to know when to restrict them in editor syntaxes. I'm sure there's a simple rule governing parameters expansions, which would clarify their valid usage contexts and limits; I just don't know it.

It might also be a good idea to specify this in the PML Reference and PML Manual documents.

[pml-lang]

Which are the valid contexts in which parameter can be expanded

There are three valid contexts:

• the value of an attribute (e.g. title="foo<<p1>>bar")
• text contained in a node, including nodes that contain raw text, such as code or html. (e.g. [div foo<<p1>>bar])
• the value of a constant (i.e. a parameter declaration can use the value of a previously defined parameter in its value (e.g. [const p2 = foo<<p1>>bar]))

specify this in the PML Reference and PML Manual documents

Yes. Added to my todo list.

[tajmone]

That's very flexible, indeed.

the value of a constant (i.e. a parameter declaration can use the value of a previously defined parameter in its value (e.g. [const p2 = foo<<p1>>bar]))

It's not clear to me whether Parameter constants can be re-defined or if they are immutable. (nowadays the term "constant" doesn't necessarily imply immutability, in some modern languages)

• If they can be redefined, are there safeguards in place to prevent recursive definitions infinite looping (e.g. [const xx = foo<<xx>>bar])? Or can PML handle this correctly?
• If immutable, is it possible to override their definition via pmlc options? (i.e. a constant defined via CLI should have higher precedence than its definition inside the source document).

[pml-lang]

It's not clear to me whether Parameter constants can be re-defined or if they are immutable

They are immutable and cannot be redefined. I will add a note in the user manual.
While constants are typically declared at the start of a document, they can also be declared later, anywhere in the document. They can be used anywhere after their declaration.
I would like to add scoping to constants (like scoping of variables/constants in C#, Java, etc.). A constant would then only be defined and accessible in the node and child-nodes in which it is declared. That would reduce the risk for name clashes in big documents or documents that share common parts.
Re-definable variables might be added later (requires safeguards, as you mentioned).

is it possible to override their definition via pmlc options?

No, not yet.

A general idea to be implemented is that configuration data can be defined as a cascade at different levels:

1. in a default configuration file located in a sub-directory of PML's installation directory
2. in an external, sharable resource (file or url) located anywhere and referenced in the PML document (overrides 1)
3. in the PML document (overrides 2)
4. as command line arguments or a config file/url referenced by a command line argument (overrides 3)