My conclusion (and I imagine Dan's but I hesitate to speak for anyone else) is:

'Whenever a constant (numeric or string) is used as an argument to a global logic (GL) or global function (GF), ProIV should internally make a copy of that constant and the GL or GF should operate on that copy. The original constant must never be modified.'

As far as the propellor-head stuff goes this just translates as 'implement pass-by-value semantics for all constants'.

This completely fixes the problem for GL and GF and does not break existing code which passes constant arguments for convenience (for example where the argument is inapplicable). The warnings generated by DS (and presumably VIP) are then superfluous but nevertheless nice to have. It is no longer important to generate errors or warnings from the gen process even though it might be nice (provided they were optional).

I think ProIV (well Tim actually, who presumably works at ProIV) say this will probably be done for GL but are suggesting it might be 'a bit hard' for GF. However, Tim has foolishly demonstrated that he is more than smart enough to fix this so I think 'we' should push them. How I don't know. Maybe we need a pressure group...

Of course, in all this we have ignored the LINK() command which has exactly the same problem. However, since LINKed code is in C and all C programmers are smart enough to wrap calls to LINK in a global logic which simulates call-by-value and to write source-code checkers to prevent mortal ProIV programmers from calling LINK directly and destroying the world, we know the problem won't arise... :-)

If it was 'intended' that constants would be mutable that's simply pathetic language design. As has been already noted, this was recognised as a mistake in Fortran IV 25 years ago, before even the precursors of ProIV existed.

Frankly I doubt that's the case at all, I think it was probably just an oversight. I'll bet there isn't a specification document covering the issue from when it was implemented.

And, the problem IS getting the attention it deserves right here, I imagine because several of us have been burnt by this particular piece of stupidity more than once.

This has been logged with you.

This was given to PROIV support on 13/04/99 (2 years ago) and has the reference number 'SHAZ-46W3SM' in your system.

It was rejected on 29/05/2001, on the grounds that it was too hard to tell if it was a literal being passed to a global function.

Now, you change your story.

If it is something that people do not want or expect it is a BUG. An enhancement is something that makes it work better / differently. And it makes no difference what you call it, its wrong that 1 = 0, it just needs to be fixed.

Rob D