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 a175d69d0734659cf294efa1aa760cc87edf1864 on tueda:loosedecl into 07cce531520082ab5bdfa16dd07f691a93a5d416 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.