Re: Renaming Fields in the D specs

Peter wrote:
>Hi Hans,
>
>I'm sorry, it's probably me, but I still don't get it.  Why isn't the
>EXTFLD() keyword enough to distinguish a program-defined subfield from an
>externally-described subfield?
>
>SEU does not allow
>
>  d oldPayment    e ds                  extname(PAYMENT)
>  d  abc                                extfld(xyz)
>
>it says "Keyword is not allowed for a parameter definition".
>
>Nor does it allow
>
>d oldPayment    e ds                  extname(PAYMENT)
>d  abc            s                   extfld(xyz)
>
>it says "LIKE keyword is expected but not found".
>
>To me this implies that I _must_ use the "E" whenever I use EXTFLD(), that
I
>_cannot_ use EXTFLD() without the "E".  Therefore, using EXTFLD() should
>simply imply the "E".  What am I missing?

You're right.  The compiler could indeed determine how to process
the statement by detecting the presence of the keyword.

It's been quite a few years since the design was done, and now I
have no idea who came up with that syntax (I don't think it was
me!), but I think it does make sense for a couple of reasons.
Basically, a compiler could indeed determine all the attributes
of a definition by examining keywords.  But then, the compiler
would have to collect all the keyword information first before it
could make sense of them.  On the other hand, if the compiler
knows what it's dealing with first, it can know how to proceed.
For example, it can give more meaningful diagnostics when it sees
the keyword, rather than having to wait until the whole definition
is processed.  Some diagnostics have to wait until more statements
are processed anyways, but getting an immediate diagnostic is a
lot easier for programmers.

The other aspect of language design is human readability.
By coding S, or DS, or PI, or PR in columns 24-25, it's
immediately clear what you're defining.  Likewise, in an
externally described data structure, the E in column 22 provides
a more immediate indication to humans reading the program what
you're reading.  Otherwise, you'd have to hunt through the
keywords (of which there may be several) to determine where the
external override specs end and the program described subfields
begin.  (OK, that's not a big deal anyways for EDS's.)

When it comes right down to it, it was simply an arbitrary
language design that was made a decade ago (probably by someone
who's no longer even in the company) and it's now simply part
of the syntax of the language.  Since the syntax has been
established, it will not likely change, and so there's no point
complaining about it.  If you don't like the syntax, and you
feel strongly enough about it, there are a lot of other
programming languages to choose from.  But then, as far as I
know, there's no language that can possibly appeal to everyone.
My current favorite programming language is Python.  It has a
very nice and clean syntax, but again, it has it's own quirks.
Although I never have any problem with it's unique indentation
rules, some people get turned off by the requirement to indent
consistently.  (What always messes me up is the rule requiring
a colon at the end of statements that introduce new nesting
levels.)  Overall, the language is very nice indeed.  But
Python will never really take off since programming is supposed
to be difficult.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com