Re: CF-Spec - another call for opinions

John,

The question is now academic since we have been promised it can be
done without potential future compatability issues.  But for the sake
of clarification, I'll answer your query.

>How would a mass recompile of existing RPG 3/4 source be affected by a new
>syntax?

The only thing that could be affected was pre-existing CF calcs.  IOW,
there would never be a case where RPG III or RPG IV fixed-format calcs
(or extended factor 2 calcs) had an exposure.

The exposure Hans referred to only happened after you started writing
in CF.  As originally proposed, it would not have let you use a
variable name or subprocedure name on a CF with an implied EVAL or
CALLP, when that name also matched an opcode.

If you used an explicit EVAL or CALLP (like option 1 required), then
it still was not an issue because the original proposal called for the
first token after the CF to be the opcode.

It was when they were asked to make the EVAL and CALLP optional, that
the possibility of ambiguous code arose.  They were evidently first
checking the leading token to see if it was an opcode, and if not,
trying to make it an implicit EVAL or CALLP.  If it was an opcode
name, it was parsed for the operands to that operation.

So when you coded   CF  Fred = Flinstone, it worked since Fred was not
an opcode at the time.  Fast forward a few releases, and now a new
opcode Fred is introduced.

Sometime after upgrading to the new release, you add some fields to a
widely used DB file.  So you do the usual mass recompile of all
programs using the record format(s) which changed.

Any program which used the name Fred as either a variable name or
subprocedure name (at least without arguments) would suddenly fail to
recompile, because it didn't have the requisite operands to the Fred
opcode.

Note that this could happen to programs without regard to how long it
had been since you made source modifications, except that it had to
have been written using CF and implied EVAL or CALLP calcs.

This condition has, to my knowledge, never happened before in the RPG
camp.  It certainly has happened to many (most?) other languages.  But
that is not justification, by itself, to break tradition in RPG when
it can be avoided without doing something like option 4.

>1) RPG III source would only be affected if a field name was changed.

RPG III would never be affected.

>2) RPG IV field name conflict. As already mentioned, use PREFIX.

IMHO, it would be easier to just add the EVAL where needed, rather
than scan and insert the prefix in front of all the file's variable
references.

>3) RPG IV procedure name conflict. 

Again, I think I'd opt for just adding CALLP where necessary.

>4) RPG IV variable name conflict. This is the same problem we've been
>dealing with in other languages for years. The actual fact of the matter is
>that it is rarely ever an issue. In fact, I don't remember ever being
>affecting by it in the 10 years that I've been writing code.

The fact it happens to other languages does not mitigate it has no
precedent in RPG history.  Most RPG programmers could care less what
happens in other languages.  On second thought, they couldn't care
very much less. <g>

>Precisely. It's a new syntax. Therefore, it should only be a concern with
>respect to new code. If you're writing fresh code, you have the opportunity
>to re-think your naming standards at that time.

But since you don't know what opcodes may be introduced in the future,
under the original rules the *possibility* still existed for a name
collision.  However remote it may have been in practice.

I don't think any RPG programmers would've switched to Hungarian
notation for naming conventions, even if it would've reduced the
chances of name collisions.

As I said, it is now a moot point.  If this didn't clear up for you
what the potential problem was, let's switch to private email to keep
it off the list.

Doug
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---