RE: It's That Time Again! The 2002 RPG Enhancement Poll

["Bob Cozzi" <cozzi@xxxxxxxxx>]

Hans,

I think for keyword expressions, I'd simply like to say things like:

D fieldx        S                80A
D myArray       S                 1A  DIM(%SIZE(fieldx)+1)

I would settle for just that kind of support vs. the following:

D FieldY        S                 7P 0 INZ(3741)
D Invoice       S                 9P 0 INZ(FieldY + 1)

I don't really care about example two (above). I just want static values
in the expression support. Field variables would be a good "next time"
function but not important for round one.

Bob Cozzi


-----Original Message-----
From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]
On Behalf Of Hans Boldt
Sent: Friday, August 23, 2002 8:15 AM
To: rpg400-l@midrange.com
Subject: Re: It's That Time Again! The 2002 RPG Enhancement Poll


Simon Coulter wrote:
 >...
>>These are the items that are $50 and over:
>>[ ]   8  $50  Allow dynamic resizing of arrays and multi-occurrence
DS.
>>[ ]  12  $50  Multiple-dimension arrays (expressions only).
>>[ ]  23  $80  Allow expressions as parameters to keywords.
>>[ ]  24  $80  Full null field support.
>>[ ]  25  $80  Procedure name overloading based on parm types.
>
>
> But I want them all !!  :-)  Not really, I do want three of them.  I
>can  accept the pricing on most of them but #23 seems extremely
>overpriced. ...

Actually, I suspect #23 is still underpriced.  We've investigated it a
number of times, and it always ends up bigger than we first thought.
Oh, we know how to do the work.  It's a matter of calling the existing
expression parser for keyword parameters, but using a different exit for
the token emit function.  It's the implementation of that function
that's the biggie.  We basically have to handle all of the expression
tokens emitted by the expression parser, even ones that don't make sense
for static expressions.

This all goes back to the original plan for implementing RPG IV. D-Specs
were considered a big priority, and so they were implemented first.
Expressions weren't as much a priority, and started with less attention
than they really deserved.  And there was indeed a risk that they
wouldn't even make it into the language!  (At least, we implemented the
keyword parser in a flexible manner, and we were able to use it later
for F-Specs, and even H-Specs.)

Hindsight is of course 20/20, and in retrospect, we should have put more
attention on the expression parser, and used that in the implementation
of keyword processing.  But at the time, the plan did make sense
considering the prevailing conditions.

Regarding expressions as keyword arguments, yes, it would be very nice.
But generally, every time we see some specific requirement, we've always
found some easier solution to implement the requirement.  Right now,
personally, I'm not aware of any specific requirement that would justify
the resources required to implement this one enhancement.  Yes, of
course it would be nice.  But at what cost?

Cheers!  Hans



_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@midrange.com To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.