Relax the statement order for symbol/$-variable declarations

[tueda]

From a forgotten Issue #188. We don't need to follow the FORTRAN style for symbol/$-variable declaration:

CF f;
L F = f(3);
S n;
id f(n?) = n;
P;
.end

[coveralls]

Coverage decreased (-0.01%) to 48.242% when pulling a175d69 on tueda:loosedecl into 07cce53 on vermaseren:master.

[benruijl]

In issue #188 you mention wanting to put ModuleOption noparallel anywhere, but noparallel is not in the allowed list of this commit. Is there a problem with that option?

[tueda]

Maybe I just forgot to add noparallel, or maybe some problem; I don't remember exactly. For consistency, other module options could be added, too.

On the other hand, if in one module both local and noparallel are specified, then it indicates some conflicts between a part that should be parallelized and a part that should be executed in the non-parallel mode. Errors/warnings could be useful in such cases.

[benruijl]

Can we simply allow all ModuleOptions to be specified anywhere in the module?

[tueda]

Maybe it would not be a problem if we give warnings/errors for inconsistent use of ModuleOptions, for example using both local and noparallel or polyratfun twice with different functions/options. The latter is dangerous because it occurs when two subroutines (procedures called in a module) assume different polyratfuns and probably leads to a wrong result.

[jodavies]

What is actually inconsistent about using both local and noparallel? This should be in the end equivalent to running the code with form or tform -w1 should it not?

[tueda]

Yes, you are right. But this potentially indicates a performance issue (parallel part and no-parallel part in a module mistakenly), which is easily found if one has to write ModuleOptions only at the end of a module while may be difficult to recognize when ModuleOptions are distributed over a big module, especially inside procedures.

[jodavies]

I think it would be interesting to resurrect this for v5?

[tueda]

Actually, which ordering relaxations should we include in version 5? Do we have consensus?

[jodavies]

Certainly the dollar-related moduleoptions were a request at the workshop. What does your code comment mean by "mixed statements"?

[vermaseren]

My suggestion would be the declarations and moduleoptions only. The declarations should occur in the input before their first use. In the past (version 1 and 2) also definitions could be anywhere in the module, but would be executed first. That was too confusing. Hence they should still be the first executable statements. The moduleoptions can in principle be anywhere, but the main problem is there, that a later moduleoption may overwrite an earlier one. That may either merit a warning, or be forbidden. Prefer to hear your opinion about that.

…

On 20 Jun 2025, at 10:33, Takahiro Ueda ***@***.***> wrote: tueda left a comment (form-dev/form#296) <#296 (comment)> Actually, which ordering relaxations should we include in version 5? Do we have consensus? — Reply to this email directly, view it on GitHub <#296 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCERVRH25SVTW6YNDMO33EPBORAVCNFSM6AAAAABRK2VHUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJQGI3TGNJSGI>. You are receiving this because you are subscribed to this thread.

[tueda]

@jodavies, by "mixed statements", I meant statements with the MIXED flag. One problem is that we now also have the MIXED2 flag.

@vermaseren, you mean all declarations and all moduleoptions are free to be relocated?? Or are exceptions only between declarations and moduleoptions? (But it is not so useful...)

[jodavies]

OK, so this means only print and printtable? The MIXED2 flag does not appear to have any associated statements?

[tueda]

Yes. So the question is the purpose of MIXED2. Maybe it was created for these declarations and module options?

[tueda]

I will open a follow-up PR that only relaxes the allowed positions of ModuleOption for $-variables (e.g., ModuleOption local). This could be adopted in version 5.