RE: Compile error - why?

We've been getting along so well Hans that I hesitate to do this <grin>, but
I think there's an important point here (to me, anyway), so I'm going to
make it.

> From: Hans Boldt
>
> Why is this restriction in place?
>

(snipping a bunch of justification)

> So on to date variables. You know there's a rule that when moving a
> character variable to a date variable, the character variable must
> be long enough to hold a date value (or vice versa).

This never made sense on outbound moves to start with, but that's just me.

(snipping some more justification)

> I suppose you could argue that we could add a check at run-time, and
> I suppose that's true. But since there were alternatives, we decided
> not to do that extra work. Now, with V5R1, there are even more
> expression alternatives to do D/T/Z manipulation.

I have a problem with this concept.  You're saying that, if there's an
alternative, you folks in the compiler time feel comfortable not doing the
extra work to support something.  This seems to me to be the opposite of
what a compiler designer should do.  The compiler designer should be
striving at all times for maximum flexibility in the language, because that
might make the programmers job easier.

Let me take a rather interesting, real world case from my old days at SSA.
SSA had a classificiation system for bugs (known as BMRs): a level A BMR was
one that significantly affected business performance and could not be worked
around, while a B BMR was the same thing but it had a workaround.

Level A BMRs were more work for the support staff, because they had to be
answered more quickly, and there were some incentive issues as well.  So it
was in the best interestes of the support staff to report as few A BMRs as
possible.

A call came in one day where under certain conditions our shop order module
was calculating required amounts incorrectly.  As you might guess, this
could cause some rather severe problems on the shop floor.  It was reported
quite logically as an A BMR.  Now, the person who was in charge of
classifying these things, having something of a vested interested in the
process, managed to come up with a very novel interpretation of the BMR
levels.  She decided that this was a B BMR, because there was a workaround:
after cutting each shop order, you could hand-compute the required
quantities with a calculator and then manually modify the shop order.

Technically, she was right, but that put the burden of work on the user, all
because our classifier didn't want to do the work (nor deal with the
consequences) associated with an A BMR.

In my mind, this isn't far afield from the decisions you're making with the
compiler.  Even though it might be easier for someone to code the simple one
line MOVE instruction from a date to a varying field, since there is an
alternative, you decide not do the work.  That's putting your own priorities
ahead of your users, and is a dangerous trend.

It's certainly not world-ending.  The work you've done on the compiler
recently is first-rate, and often outstanding, above and beyond the call.
But the decisions you make as to what should or shouldn't be in the compiler
sometimes lack a sense of "what would the user want".  Instead, they seem
occasionally to fall into the category of "what would be easier for us" and
frankly, unless it's a matter of gargantuan amounts of work, the fact that
it's not easy for you isn't our concern.  Come on now, if it was EASY,
everybody would write compilers.

I guess it's not for me to say, I don't fund the operation except indirectly
as an end user.  But I sure would like to know that you guys are thinking of
us poor users when these decisions come up.


> (Oh BTW, if you want to do level breaks on integer input fields (or
> any other of the unsupported types), just define a character field
> in that field position, and code the level indicator on that field.)

Does this work on negative integers?

Joe