ModuleOption behaviour for $-variables

[tueda]

Currently, FORM refuses the following program due to the statement order:

On code;
$a = 0;
ModuleOption local, $a;
multiply 1;
.end

FORM 5.0.0-beta.1 (Dec 19 2025, v5.0.0-beta.1-288-g73a6a14)  Run: Thu Jan  8 18:36:18 2026
    On code;
    $a = 0;
    ModuleOption local, $a;
    multiply 1;
test.frm Line 4 --> Statement out of order
test.frm Line 4 --> Proper order inside a module is:
Declarations, specifications, definitions, statements, output control statement
s

It is easy to relax this constraint so that the above example runs. See #296. An example implementation is here.

But then, how should we handle the following cases?

Case 1

ModuleOption local, $a;
$a = 0;
.end

At the ModuleOption statement, $a is undefined. So giving a warning and not making $a local would be an option:

test.frm Line 1 --> Warning: &Undefined $-variable in module statement

But users might reasonably expect $a to become local, if it is used in the same module.

Case 2

$a = 0;
ModuleOption local, $a;
ModuleOption sum, $a;
.end

Here, $a gets conflicting options, local vs. sum. Should it be local or sum? Should this be a warning or an error?

Currently, FORM makes it local and ignores sum without giving any warning.

[jodavies]

I would say that in case 1, there should be an error: the dollar should be defined before the moduleoption statement is valid.

In case 2, we could also make conflicting moduleoptions an error, which leads to well defined and unambiguous behaviour. This one may break existing user scripts, however.

[tueda]

And v5.0 is a good time to introduce breaking changes for existing ambiguous user scripts.

[tueda]

It turned out that giving compiler errors instead of compiler warnings in ModuleOption local and similar cases is messy. DoModDollar has no mechanism for propagating errors, so it requires changing its prototype. Why didn't humans invent std::expected in the 80's...?