Contract signatures cannot express zero-argument operations

[tburny]

What goes wrong

A contract operation signature requires at least one parameter. There is no
way to declare a zero-argument operation: both the empty-parameter-list form
name: () -> ReturnType and the bare-arrow form name: -> ReturnType fail to
parse. This forces a nominal dummy parameter as a workaround.

Why it matters

Zero-argument operations are common at integration boundaries: listing all
items, fetching global state, health checks. When modelling such a boundary as
a contract (the language's recommended construct for code-to-code surfaces per
patterns.md Pattern 9), every parameterless operation has to carry a fake
argument, which leaks an implementation artefact into the spec and makes a
signature-level comparison against the real API noisier.

Steps to reproduce

a-empty-parens.allium:

-- allium: 3

value Foo { value: String }

contract Demo {
    list_things: () -> Set<Foo>
}

Run allium check a-empty-parens.allium.

b-bare-arrow.allium: same file, signature line replaced with
list_things: -> Set<Foo>.

Expected behaviour

At least one of the two forms parses and declares a zero-argument operation
returning Set<Foo>. (name: () -> ReturnType is the conventional choice in
most signature grammars.)

Actual behaviour

Both forms produce a parse error on the signature line:

• () -> ... produces expected expression (identifier, number, string, true/false, null, if/for/not/exists, '(', '{', '['), found ')'
• -> ... produces expected expression (...), found '->'

The parser treats the contract signature body as an expression position and
expects a parameter expression where the empty list or arrow appears.

Workaround

A nominal unit parameter parses cleanly:

contract Demo {
    list_things: (_unit: Any) -> Set<Foo>
}

This is what we are using in production specs, but _unit: Any is noise that
exists only to satisfy the grammar.

Environment

• Version: allium 3.2.3 (language versions: 1, 2, 3)
• Spec language version: -- allium: 3
• Frequency: always (deterministic parse error)

Out of scope

• Variadic / optional parameter syntax
• Whether Any should be discouraged elsewhere
• Return-type grammar (only the parameter list is at issue here)

Related

• Contract / signature grammar: skills/allium/references/language-reference.md (Contracts section)
• Pattern 9 "Framework Integration Contract": skills/allium/references/patterns.md
• Same class of grammar enhancement: Allow backtick-quoted field names in value blocks #22 (backtick-quoted field names)